summaryrefslogtreecommitdiffstats
path: root/mlir/lib/IR/MLIRContext.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Support for affine integer setsUday Bondhugula2019-03-291-0/+25
| | | | | | | | | | | | | - introduce affine integer sets into the IR - parse and print affine integer sets (both inline or outlined) similar to affine maps - use integer set for IfStmt's conditional, and implement parsing of IfStmt's conditional - fixed an affine expr paren omission bug while one this. TODO: parse/represent/print MLValue operands to affine integer set references. PiperOrigin-RevId: 207779408
* Continue wiring up diagnostic reporting infrastructure, still WIP.Chris Lattner2019-03-291-12/+11
| | | | | | | | | | | | - Implement a diagnostic hook in one of the paths in mlir-opt which captures and reports the diagnostics nicely. - Have the parser capture simple location information from the parser indicating where each op came from in the source .mlir file. - Add a verifyDominance() method to MLFuncVerifier to demo this, resolving b/112086163 - Add some PrettyStackTrace handlers to make crashes in the testsuite easier to track down. PiperOrigin-RevId: 207488548
* [mlir] Add a TypeAttr class, allow type attributesJames Molloy2019-03-291-0/+11
| | | | PiperOrigin-RevId: 207235956
* [mlir] Add a string typeJames Molloy2019-03-291-4/+8
| | | | PiperOrigin-RevId: 206977161
* Enhance MLIRContext and operations with the ability to register diagnosticChris Lattner2019-03-291-4/+38
| | | | | | | | | | | | handlers and to feed them with errors and warnings produced by the compiler. Enhance Operation to be able to get its own MLIRContext on demand, simplifying some clients. Change the verifier to emit certain errors with the diagnostic handler. This is steps towards reworking the verifier and diagnostic propagation but is itself not particularly useful. More to come. PiperOrigin-RevId: 206948643
* Eliminate "primitive" types from being a thing, splitting them into FloatTypeChris Lattner2019-03-291-18/+46
| | | | | | | | | | | | | | and OtherType. Other type is now the thing that holds AffineInt, Control, eventually Resource, Variant, String, etc. FloatType holds the floating point types, and allows convenient query of isa<FloatType>(). This fixes issues where we allowed control to be the element type of tensor, memref, vector. At the same time, ban AffineInt from being an element of a vector/memref/tensor as well since we don't need it. I updated the spec to match this as well. PiperOrigin-RevId: 206361942
* Fix/clean up convoluted AffineBinaryOpExpr::get.Uday Bondhugula2019-03-291-21/+14
| | | | | | | | | The code for this has been convoluted. We shouldn't be doing a "*result = simplified" below at 703 since the simplified expression would have already been inserted by a simplify* method, whether it was a binary op expr or something else. PiperOrigin-RevId: 206114115
* Unique AffineDimExpr, AffineSymbolExpr, AffineConstantExpr, and allocate theseUday Bondhugula2019-03-291-9/+45
| | | | | | | | from the bump pointer allocator. - delete AffineExpr destructors. PiperOrigin-RevId: 205943807
* [mlir] Fix a use-after-free iterator error found by asanJames Molloy2019-03-291-7/+10
| | | | | | | | While fixing this the parser-affine-map.mlir test started failing due to ordering of the printed affine maps. Even the existing CHECK-DAGs weren't enough to disambiguate; a partial match on one line precluded a total match on a following line. The fix for this was easy - print the affine maps in reference order rather than in DenseMap iteration order. PiperOrigin-RevId: 205843770
* Vector types elementtype can be either PrimitiveType or IntegerType.Jacques Pienaar2019-03-291-1/+1
| | | | | | Change the type of elementType and remove the cast to PrimitiveType. PiperOrigin-RevId: 205698221
* [mlir] clang-formatJames Molloy2019-03-291-69/+66
| | | | | | Mostly whitespace changes, but this makes these files clang-format clean. PiperOrigin-RevId: 205697599
* Simplify affine binary op expression class hierarchyUday Bondhugula2019-03-291-33/+0
| | | | | | | | | | | | | | | - 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
* Support for AffineMapAttr.MLIR Team2019-03-291-0/+11
| | | | PiperOrigin-RevId: 205157390
* Adds MemRef type and adds support for parsing memref affine map composition.MLIR Team2019-03-291-0/+61
| | | | PiperOrigin-RevId: 204756982
* Comment fixes for affine map range size parsing.Uday Bondhugula2019-03-291-3/+1
| | | | PiperOrigin-RevId: 204399402
* Parse affine map range sizes.Uday Bondhugula2019-03-291-5/+14
| | | | PiperOrigin-RevId: 204240947
* Implement some simple affine expr canonicalization/simplification.Uday Bondhugula2019-03-291-103/+64
| | | | | | | | | | | | | | | - fold constants when possible. - for a mul expression, canonicalize to always keep the LHS as the constant/symbolic term, and similarly, the RHS for an add expression to keep it closer to the mathematical form. (Eg: f(x) = 3*x + 5)); other similar simplifications; - verify binary op expressions at creation time. TODO: we can completely drop AffineSubExpr, and instead use add and mul by -1. This way something like x - 4 and -4 + x get canonicalized to x + -1 * 4 instead of being x - 4 and x + -4. (The other alternative if wanted to retain AffineSubExpr would be to simplify x + -1*y to x - y and x + <neg number> to x - <pos number>). PiperOrigin-RevId: 204240258
* Complete affine expr parsing supportUday Bondhugula2019-03-291-27/+90
| | | | | | | | | | - 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
* Implement a simple IR verifier, including support for custom ops adding theirChris Lattner2019-03-291-0/+8
| | | | | | own requirements. PiperOrigin-RevId: 203497491
* Implement Uday's suggestion to unique attribute lists across instructions,Chris Lattner2019-03-291-0/+94
| | | | | | | | | 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
* Add the ability to have "Ops" defined as small C++ classes, with some niceChris Lattner2019-03-291-1/+12
| | | | | | | | | | | | | | | | | properties: - They allow type checked dynamic casting from their base Operation. - They allow nice accessors for C++ clients, e.g. a "getIndex()" method on 'dim' that returns an unsigned. - They work with both OperationInst/OperationStmt (once OperationStmt is implemented). - They get custom printing logic. They will eventually get custom parsing, verifier, and builder logic as well. - Out of tree clients can register their own operation set without having to change MLIR core, e.g. for TensorFlow or custom target instructions. This registers addf and dim as examples. PiperOrigin-RevId: 203382993
* Implement IR support for attributes.Chris Lattner2019-03-291-25/+124
| | | | PiperOrigin-RevId: 203293376
* Clean up the implementation of Type, making it structurally more similar toChris Lattner2019-03-291-4/+4
| | | | | | Instruction and AffineExpr. NFC. PiperOrigin-RevId: 203287117
* Clean up an MLIRContext commentUday Bondhugula2019-03-291-4/+2
| | | | PiperOrigin-RevId: 203227287
* Parsing support for affine maps and affine expressionsUday Bondhugula2019-03-291-21/+104
| | | | | | | | 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
* Enhance the type system to support arbitrary precision integers, which areChris Lattner2019-03-291-31/+16
| | | | | | | | | 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
* [WIP] Sketching IR and parsing support for affine maps, affine expressionsUday Bondhugula2019-03-291-0/+72
| | | | | | | | | | | 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
* Sketch out parser/IR support for OperationInst, and a new Instruction baseChris Lattner2019-03-291-1/+27
| | | | | | | | | | 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
* Remove unused UnrankedTensorTypeKeyInfo.MLIR Team2019-03-291-16/+0
| | | | PiperOrigin-RevId: 201830967
* Add tensor type.MLIR Team2019-03-291-0/+108
| | | | PiperOrigin-RevId: 201830793
* Introduce IR support for MLIRContext, primitive types, function types, andChris Lattner2019-03-291-0/+200
vector types. tensors and memref types are still TODO, and would be a good starter project for someone. PiperOrigin-RevId: 201782748
OpenPOWER on IntegriCloud