| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pass op token location where necessary so that errors on non-affine expressions
are reported with accurate/meaningful location pointers.
Before:
/tmp/parser-affine-map-single.mlir:2:39: error: non-affine expression: at least one of the multiply operands has to be either a constant or symbolic
#hello_world = (i, j) [s0, s1] -> (i*j, j)
^
After:
/tmp/parser-affine-map-single.mlir:2:37: error: non-affine expression: at least one of the multiply operands has to be either a constant or symbolic
#hello_world = (i, j) [s0, s1] -> (i*j, j)
^
PiperOrigin-RevId: 205458508
|
|
|
|
|
|
|
|
|
|
| |
is still limited in several ways, which i'll build out in subsequent patches.
Rename the accessor for inst operands/results to make the Operand/Result
versions of these more obscure, allowing getOperand/getResult to traffic
in values (which is what - by far - most clients actually care about).
PiperOrigin-RevId: 205408439
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Drop sub-classing of affine binary op expressions.
- Drop affine expr op kind sub. Represent it as multiply by -1 and add. This
will also be in line with the math form when we'll need to represent a system of
linear equalities/inequalities: the negative number goes into the coefficient
of an affine form. (For eg. x_1 + (-1)*x_2 + 3*x_3 + (-2) >= 0). The folding
simplification will transparently deal with multiplying the -1 with any other
constants. This also means we won't need to simplify a multiply expression
like in x_1 + (-2)*x_2 to a subtract expression (x_1 - 2*x_2) for
canonicalization/uniquing.
- When we print the IR, we will still pretty print to a subtract when possible.
PiperOrigin-RevId: 205298958
|
|
|
|
| |
PiperOrigin-RevId: 205288794
|
|
|
|
|
|
|
|
| |
loop header.
Loop bounds and presumed to be constants for now and are stored in ForStmt as affine constant expressions. ML function arguments, return statement operands and loop variable name are dropped for now.
PiperOrigin-RevId: 205256208
|
|
|
|
|
|
|
|
|
|
|
| |
- This introduces a new FunctionParser base class to handle logic common
between the kinds of functions we have, e.g. ssa operand/def parsing.
- This introduces a basic symbol table (without support for forward
references!) and links defs and uses.
- CFG functions now parse and build operand lists for operations. The printer
isn't set up for them yet tho.
PiperOrigin-RevId: 205246110
|
|
|
|
| |
PiperOrigin-RevId: 205157390
|
|
|
|
|
|
|
|
|
|
|
| |
the instruction side of the house.
This has a number of limitations, including that we are still dropping
operands on the floor in the parser. Also, most of the convenience methods
aren't wired up yet. This is enough to get result type lists round tripping
through.
PiperOrigin-RevId: 205148223
|
|
|
|
| |
PiperOrigin-RevId: 204999887
|
|
|
|
|
|
|
| |
Refactors operation parsing to share functionality between CFG and ML functions. ML function construction now goes through a builder, similar to the way it is done for
CFG functions.
PiperOrigin-RevId: 204779279
|
|
|
|
| |
PiperOrigin-RevId: 204756982
|
|
|
|
|
|
|
| |
is no strong reason to prefer one or the other, but // is nice for consistency
given the rest of the compiler is written in C++.
PiperOrigin-RevId: 204628476
|
|
|
|
|
|
| |
Use LLVM double-link with parent list to store statements within a block.
PiperOrigin-RevId: 204515541
|
|
|
|
| |
PiperOrigin-RevId: 204399402
|
|
|
|
| |
PiperOrigin-RevId: 204240947
|
|
|
|
|
|
| |
Fixes use-after-free ASAN failure.
PiperOrigin-RevId: 204177796
|
|
|
|
|
|
| |
Previously the errorReporter was incorrectly moved post creating the Lexer.
PiperOrigin-RevId: 204077155
|
|
|
|
|
|
|
|
|
|
| |
use it.
This also removes "operand" from the affine expr classes: it is unnecessary
verbosity and "operand" will mean something very specific for SSA stuff (we
will have an Operand type).
PiperOrigin-RevId: 203976504
|
|
|
|
|
|
|
|
| |
and AffineMapParser to localize the parsing productions that only
make sense at the top level of a module, and within an affine map,
respectively. NFC.
PiperOrigin-RevId: 203966841
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
state into their own specialized parser subclasses. This is important,
because a monolithic parser grows very large very quickly and we're already
getting big.
Doing this requires splitting mutable parser state out from Parser to its
own ParserState class or into transient subclasses like CFGParser. This
works better than having things like CFGFuncParserState which gets passed
around everywhere, because we can put the parser methods on the
new classes.
This patch just does CFGFunc and MLFunc, but I'll follow up with AffineMaps
(unless someone else wants to take it).
PiperOrigin-RevId: 203871695
|
|
|
|
|
|
|
|
| |
affine expr parsing.
- also make error messages uniform
PiperOrigin-RevId: 203822686
|
|
|
|
|
|
|
|
|
|
| |
- check for non-affine expressions
- handle negative numbers and negation of id's, expressions
- functions to check if a map is pure affine or semi-affine
- simplify/clean up affine map parsing code
- report more errors messages, more accurate error messages
PiperOrigin-RevId: 203773633
|
|
|
|
|
|
| |
prone to create things.
PiperOrigin-RevId: 203703229
|
|
|
|
|
|
|
| |
isn't actually constructing IR objects yet, it is eating the tokens and
discarding them.
PiperOrigin-RevId: 203616265
|
|
|
|
|
|
|
| |
This avoids fall-through error in opt mode:
error: unannotated fall-through between switch labels
[-Werror,-Wimplicit-fallthrough]
PiperOrigin-RevId: 203616256
|
|
|
|
|
|
| |
own requirements.
PiperOrigin-RevId: 203497491
|
|
|
|
|
|
|
|
|
| |
reducing the memory impact on Operation to one word instead of 3 from an
std::vector.
Implement Jacques' suggestion to merge OpImpl::Storage into OpImpl::Base.
PiperOrigin-RevId: 203426518
|
|
|
|
|
|
|
| |
for attributes on operations. Split Operation out from OperationInst so it
can be shared with OperationStmt one day.
PiperOrigin-RevId: 203325366
|
|
|
|
|
|
|
|
| |
A recursive descent parser for affine maps/expressions with operator precedence and
associativity. (While on this, sketch out uniqui'ing functionality for affine maps
and affine binary op expressions (partly).)
PiperOrigin-RevId: 203222063
|
|
|
|
|
|
| |
if statement conditions are not yet supported.
PiperOrigin-RevId: 203211526
|
|
|
|
|
|
| |
Add a default error reporter for the parser that uses the SourceManager to print the error. Also and OptResult enum (mirroring ParseResult) to make the behavior self-documenting.
PiperOrigin-RevId: 203173647
|
|
|
|
|
|
|
| |
in a container automatically maintain their parent pointers, and change storage
from std::vector to the proper llvm::iplist type.
PiperOrigin-RevId: 202889037
|
|
|
|
|
|
|
|
|
| |
important for low-bitwidth inference cases and hardware synthesis targets.
Rename 'int' to 'affineint' to avoid confusion between "the integers" and "the int
type".
PiperOrigin-RevId: 202751508
|
|
|
|
|
|
|
|
|
|
|
| |
Run test case:
$ mlir-opt test/IR/parser-affine-map.mlir
test/IR/parser-affine-map.mlir:3:30: error: expect '(' at start of map range
#hello_world2 (i, j) [s0] -> i+s0, j)
^
PiperOrigin-RevId: 202736856
|
|
|
|
|
|
|
|
| |
to share code a bit more, and fixes a diagnostic bug Uday pointed out where
parseCommaSeparatedList would print the wrong diagnostic when the end signifier
was not a ).
PiperOrigin-RevId: 202676858
|
|
|
|
|
|
|
|
|
|
| |
class.
Introduce an Identifier class to MLIRContext to represent uniqued identifiers,
introduce string literal support to the lexer, introducing parser and printer
support etc.
PiperOrigin-RevId: 202592007
|
|
|
|
|
|
|
| |
Representing function arguments is still TODO.
Supporting instructions other than return is also TODO.
PiperOrigin-RevId: 202570934
|
|
|
|
|
|
|
|
| |
- parsing affine map identifiers
- place-holder classes for AffineMap
- module contains a list of affine maps (defined at the top level).
PiperOrigin-RevId: 202336919
|
|
|
|
|
|
| |
Add diagnostic reporter function to lexer/parser and use that from mlir-opt to report errors instead of having the lexer/parser print the errors.
PiperOrigin-RevId: 201892004
|
|
|
|
|
|
| |
references.
PiperOrigin-RevId: 201872745
|
|
|
|
| |
PiperOrigin-RevId: 201830793
|
|
|
|
|
|
|
|
|
|
| |
instruction.
This is pretty much minimal scaffolding for this step. Basic block arguments,
instructions, other terminators, a proper IR representation for
blocks/instructions, etc are all coming.
PiperOrigin-RevId: 201826439
|
|
|
|
|
|
|
|
|
| |
vector types.
tensors and memref types are still TODO, and would be a good starter project
for someone.
PiperOrigin-RevId: 201782748
|
|
|
|
|
|
|
|
| |
Semi-affine maps and address spaces are not yet supported (someone want to take
this on?). We also don't generate IR objects for types yet, which I plan to
tackle next.
PiperOrigin-RevId: 201754283
|
|
arguments.
PiperOrigin-RevId: 201706570
|