summaryrefslogtreecommitdiffstats
path: root/mlir/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
...
* Affine map composition.MLIR Team2019-03-291-0/+9
| | | | | | | | *) Implements AffineValueMap forward substitution for AffineApplyOps. *) Adds ComposeAffineMaps transformation pass, which composes affine maps for all loads/stores in an MLFunction. *) Adds multiple affine map composition tests. PiperOrigin-RevId: 216216446
* [MLIR] Cleanup AffineExprNicolas Vasilache2019-03-295-317/+318
| | | | | | | | | | | | | | | | | | | | | | | | This CL introduces a series of cleanups for AffineExpr value types: 1. to make it clear that the value types should be used, the pointer AffineExpr types are put in the detail namespace. Unfortunately, since the value type operator-> only forwards to the underlying pointer type, we still need to expose this in the include file for now; 2. AffineExprKind is ok to use, it thus comes out of detail and thus of AffineExpr 3. getAffineDimExpr, getAffineSymbolExpr, getAffineConstantExpr are similarly extracted as free functions and their naming is mande consistent across Builder, MLContext and AffineExpr 4. AffineBinaryOpEx::simplify functions are made into static free functions. In particular it is moved away from AffineMap.cpp where it does not belong 5. operator AffineExprType is made explicit 6. uses the binary operators everywhere possible 7. drops the pointer usage everywhere outside of AffineExpr.cpp, MLIRContext.cpp and AsmPrinter.cpp PiperOrigin-RevId: 216207212
* [MLIR] Value types for AffineXXXExprNicolas Vasilache2019-03-293-59/+47
| | | | | | | | | | | | | | | | | | | | | This CL makes AffineExprRef into a value type. Notably: 1. drops llvm isa, cast, dyn_cast on pointer type and uses member functions on the value type. It may be possible to still use classof (in a followup CL) 2. AffineBaseExprRef aggressively casts constness away: if we mean the type is immutable then let's jump in with both feet; 3. Drop implicit casts to the underlying pointer type because that always results in surprising behavior and is not needed in practice once enough cleanup has been applied. The remaining negative I see is that we still need to mix operator. and operator->. There is an ugly solution that forwards the methods but that ends up duplicating the class hierarchy which I tried to avoid as much as possible. But maybe it's not that bad anymore since AffineExpr.h would still contain a single class hierarchy (the duplication would be impl detail in.cpp) PiperOrigin-RevId: 216188003
* Rename affineint type to index type. The name 'index' may not be perfect, ↵Chris Lattner2019-03-294-30/+29
| | | | | | | | | | | | | | but is better than the old name. Here is some justification: 1) affineint (as it is named) is not a type suitable for general computation (e.g. the multiply/adds in an integer matmul). It has undefined width and is undefined on overflow. They are used as the indices for forstmt because they are intended to be used as indexes inside the loop. 2) It can be used in both cfg and ml functions, and in cfg functions. As you mention, “symbols” are not affine, and we use affineint values for symbols. 3) Integers aren’t affine, the algorithms applied to them can be. :) 4) The only suitable use for affineint in MLIR is for indexes and dimension sizes (i.e. the bounds of those indexes). PiperOrigin-RevId: 216057974
* Constant folding for loop bounds.Uday Bondhugula2019-03-293-84/+166
| | | | | | | | | | | | | | - Fold the lower/upper bound of a loop to a constant whenever the result of the application of the bound's affine map on the operand list yields a constant. - Update/complete 'for' stmt's API to set lower/upper bounds with operands. Resolve TODOs for ForStmt::set{Lower,Upper}Bound. - Moved AffineExprConstantFolder into AffineMap.cpp and added AffineMap::constantFold to be used by both AffineApplyOp and ForStmt::constantFoldBound. PiperOrigin-RevId: 215997346
* Implement support for constant folding operations even when their operands areChris Lattner2019-03-291-29/+57
| | | | | | not all constant. Implement support for folding dim, x*0, and affine_apply. PiperOrigin-RevId: 215917432
* Introduce memref replacement/rewrite support: to replace an existing memrefUday Bondhugula2019-03-291-0/+12
| | | | | | | | | | | | | | | with a new one (of a potentially different rank/shape) with an optional index remapping. - introduce Utils::replaceAllMemRefUsesWith - use this for DMA double buffering (This CL also adds a few temporary utilities / code that will be done away with once: 1) abstract DMA op's are added 2) memref deferencing side-effect / trait is available on op's 3) b/117159533 is resolved (memref index computation slices). PiperOrigin-RevId: 215831373
* [RFC][MLIR] Use AffineExprRef in place of AffineExpr* in IRNicolas Vasilache2019-03-297-106/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL starts by replacing AffineExpr* with value-type AffineExprRef in a few places in the IR. By a domino effect that is pretty telling of the inconsistencies in the codebase, const is removed where it makes sense. The rationale is that the decision was concisously made that unique'd types have pointer semantics without const specifier. This is fine but we should be consistent. In the end, the only logical invariant is that there should never be such a thing as a const AffineExpr*, const AffineMap* or const IntegerSet* in our codebase. This CL takes a number of shortcuts to killing const with fire, in particular forcing const AffineExprRef to return the underlying non-const AffineExpr*. This will be removed once AffineExpr* has disappeared in containers but for now such shortcuts allow a bit of sanity in this long quest for cleanups. The **only** places where const AffineExpr*, const AffineMap* or const IntegerSet* may still appear is by transitive needs from containers, comparison operators etc. There is still one major thing remaining here: figure out why cast/dyn_cast return me a const AffineXXX*, which in turn requires a bunch of ugly const_casts. I suspect this is due to the classof taking const AffineXXXExpr*. I wonder whether this is a side effect of 1., if it is coming from llvm itself (I'd doubt it) or something else (clattner@?) In light of this, the whole discussion about const makes total sense to me now and I would systematically apply the rule that in the end, we should never have any const XXX in our codebase for unique'd types (assuming we can remove them all in containers and no additional constness constraint is added on us from the outside world). PiperOrigin-RevId: 215811554
* [MLIR] Templated AffineExprBaseRefNicolas Vasilache2019-03-294-95/+72
| | | | | | | | | | | | | | | | | | | This CL implements AffineExprBaseRef as a templated type to allow LLVM-style casts to work properly. This also allows making AffineExprBaseRef::expr private. To achieve this, it is necessary to use llvm::simplify_type and make AffineConstExpr derive from both AffineExpr and llvm::simplify<AffineExprRef>. Note that llvm::simplify_type is just an interface to enable the proper template resolution of isa/cast/dyn_cast but it otherwise holds no value. Lastly note that certain dyn_cast operations wanted the const AffineExpr* form of AffineExprBaseRef so I made the implicit constructor take that by default and documented the immutable behavior. I think this is consistent with the decision to make unique'd type immutable by convention and never use const on them. PiperOrigin-RevId: 215642247
* [MLIR] Remove uses of AffineExpr* outside of IRNicolas Vasilache2019-03-295-59/+68
| | | | | | | | | | | | | This CL uniformizes the uses of AffineExprWrap outside of IR. The public API of AffineExpr builder is modified to only use AffineExprWrap. A few places access AffineExprWrap.expr, this is only while the API is in transition to easily keep track (i.e. make expr private and let the compiler track the errors). Parser.cpp exhibits patterns that are dependent on nullptr values so converting it is left for another CL. PiperOrigin-RevId: 215642005
* [MLIR] AffineExpr lightweight value type for operatorsNicolas Vasilache2019-03-293-10/+53
| | | | | | | | | | | | | | | | | | | | | This CL proposes adding MLIRContext* to AffineExpr as discussed previously. This allows the value class to not require the context in its constructor and makes it a POD that it makes sense to pass by value everywhere. A list of other RFC CLs will build on this. The RFC CLs are small incremental pushes of the API which would be a pretty big change otherwise. Pushing the thinking a little bit more it seems reasonable to use implicit cast/constructor to/from AffineExpr*. As this thing evolves, it looks to me like IR (and probably Parser, for not so good reasons) want to operate on AffineExpr* and the rest of the code wants to operate on the value type. For this reason I think AffineExprImpl*/AffineExpr may also make sense but I do not have a particular naming preference. The jury is still out for naming decision between the above and AffineExprBase*/AffineExpr or AffineExpr*/AffineExprRef. PiperOrigin-RevId: 215641596
* [MLIR] Use chainable ligthweight wrapper for AffineExprNicolas Vasilache2019-03-292-37/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL argues that the builder API for AffineExpr should be used with a lightweight wrapper that supports operators chaining. This CL takes the ill-named AffineExprWrap and proposes a simple set of operators with builtin constant simplifications. This allows: 1. removing the getAddMulPureAffineExpr function; 2. avoiding concerns about constant vs non-constant simplifications at **every call site**; 3. writing the mathematical expressions we want to write without unnecessary obfuscations. The points above represent pure technical debt that we don't want to carry on. It is important to realize that this is not a mere convenience or "just sugar" but reduction in cognitive overhead. This thinking can be pushed significantly further, I have added some comments with some basic ideas but we could make AffineMap, AffineApply and other objects that use map applications more functional and value-based. I am putting this out to get a first batch of reviews and see what people think. I think in my preferred design I would have the Builder directly return such AffineExprPtr objects by value everywhere and avoid the boilerplate explicit creations that I am doing by hand at this point. Yes this AffineExprPtr would implicitly convert to AffineExpr* because that is what it is. PiperOrigin-RevId: 215641317
* Fix MLIR's floordiv, ceildiv, and mod for constant inputs (for negative lhs's)Uday Bondhugula2019-03-292-17/+13
| | | | | | | | - introduce mlir::{floorDiv, ceilDiv, mod} for constant inputs in mlir/Support/MathExtras.h - consistently use these everywhere in IR, Analysis, and Transforms. PiperOrigin-RevId: 215580677
* Add support to Add, Sub, Mul for both Integer and Float types.Feng Liu2019-03-291-6/+72
| | | | | | The new operations are registered and also the const folding of them are implemented. PiperOrigin-RevId: 215575999
* Introduce loop body skewing / loop pipelining / loop shifting utility.Uday Bondhugula2019-03-292-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - loopBodySkew shifts statements of a loop body by stmt-wise delays, and is typically meant to be used to: - allow overlap of non-blocking start/wait until completion operations with other computation - allow shifting of statements (for better register reuse/locality/parallelism) - software pipelining (when applied to the innermost loop) - an additional argument specifies whether to unroll the prologue and epilogue. - add method to check SSA dominance preservation. - add a fake loop pipeline pass to test this utility. Sample input/output are below. While on this, fix/add following: - fix minor bug in getAddMulPureAffineExpr - add additional builder methods for common affine map cases - fix const_operand_iterator's for ForStmt, etc. When there is no such thing as 'const MLValue', the iterator shouldn't be returning const MLValue's. Returning MLValue is const correct. Sample input/output examples: 1) Simplest case: shift second statement by one. Input: for %i = 0 to 7 { %y = "foo"(%i) : (affineint) -> affineint %x = "bar"(%i) : (affineint) -> affineint } Output: #map0 = (d0) -> (d0 - 1) mlfunc @loop_nest_simple1() { %c8 = constant 8 : affineint %c0 = constant 0 : affineint %0 = "foo"(%c0) : (affineint) -> affineint for %i0 = 1 to 7 { %1 = "foo"(%i0) : (affineint) -> affineint %2 = affine_apply #map0(%i0) %3 = "bar"(%2) : (affineint) -> affineint } %4 = affine_apply #map0(%c8) %5 = "bar"(%4) : (affineint) -> affineint return } 2) DMA overlap: shift dma.wait and compute by one. Input for %i = 0 to 7 { %pingpong = affine_apply (d0) -> (d0 mod 2) (%i) "dma.enqueue"(%pingpong) : (affineint) -> affineint %pongping = affine_apply (d0) -> (d0 mod 2) (%i) "dma.wait"(%pongping) : (affineint) -> affineint "compute1"(%pongping) : (affineint) -> affineint } Output #map0 = (d0) -> (d0 mod 2) #map1 = (d0) -> (d0 - 1) #map2 = ()[s0] -> (s0 + 7) mlfunc @loop_nest_dma() { %c8 = constant 8 : affineint %c0 = constant 0 : affineint %0 = affine_apply #map0(%c0) %1 = "dma.enqueue"(%0) : (affineint) -> affineint for %i0 = 1 to 7 { %2 = affine_apply #map0(%i0) %3 = "dma.enqueue"(%2) : (affineint) -> affineint %4 = affine_apply #map1(%i0) %5 = affine_apply #map0(%4) %6 = "dma.wait"(%5) : (affineint) -> affineint %7 = "compute1"(%5) : (affineint) -> affineint } %8 = affine_apply #map1(%c8) %9 = affine_apply #map0(%8) %10 = "dma.wait"(%9) : (affineint) -> affineint %11 = "compute1"(%9) : (affineint) -> affineint return } 3) With arbitrary affine bound maps: Shift last two statements by two. Input: for %i = %N to ()[s0] -> (s0 + 7)()[%N] { %y = "foo"(%i) : (affineint) -> affineint %x = "bar"(%i) : (affineint) -> affineint %z = "foo_bar"(%i) : (affineint) -> (affineint) "bar_foo"(%i) : (affineint) -> (affineint) } Output #map0 = ()[s0] -> (s0 + 1) #map1 = ()[s0] -> (s0 + 2) #map2 = ()[s0] -> (s0 + 7) #map3 = (d0) -> (d0 - 2) #map4 = ()[s0] -> (s0 + 8) #map5 = ()[s0] -> (s0 + 9) for %i0 = %arg0 to #map0()[%arg0] { %0 = "foo"(%i0) : (affineint) -> affineint %1 = "bar"(%i0) : (affineint) -> affineint } for %i1 = #map1()[%arg0] to #map2()[%arg0] { %2 = "foo"(%i1) : (affineint) -> affineint %3 = "bar"(%i1) : (affineint) -> affineint %4 = affine_apply #map3(%i1) %5 = "foo_bar"(%4) : (affineint) -> affineint %6 = "bar_foo"(%4) : (affineint) -> affineint } for %i2 = #map4()[%arg0] to #map5()[%arg0] { %7 = affine_apply #map3(%i2) %8 = "foo_bar"(%7) : (affineint) -> affineint %9 = "bar_foo"(%7) : (affineint) -> affineint } 4) Shift one by zero, second by one, third by two for %i = 0 to 7 { %y = "foo"(%i) : (affineint) -> affineint %x = "bar"(%i) : (affineint) -> affineint %z = "foobar"(%i) : (affineint) -> affineint } #map0 = (d0) -> (d0 - 1) #map1 = (d0) -> (d0 - 2) #map2 = ()[s0] -> (s0 + 7) %c9 = constant 9 : affineint %c8 = constant 8 : affineint %c1 = constant 1 : affineint %c0 = constant 0 : affineint %0 = "foo"(%c0) : (affineint) -> affineint %1 = "foo"(%c1) : (affineint) -> affineint %2 = affine_apply #map0(%c1) %3 = "bar"(%2) : (affineint) -> affineint for %i0 = 2 to 7 { %4 = "foo"(%i0) : (affineint) -> affineint %5 = affine_apply #map0(%i0) %6 = "bar"(%5) : (affineint) -> affineint %7 = affine_apply #map1(%i0) %8 = "foobar"(%7) : (affineint) -> affineint } %9 = affine_apply #map0(%c8) %10 = "bar"(%9) : (affineint) -> affineint %11 = affine_apply #map1(%c8) %12 = "foobar"(%11) : (affineint) -> affineint %13 = affine_apply #map1(%c9) %14 = "foobar"(%13) : (affineint) -> affineint 5) SSA dominance violated; no shifting if a shift is specified for the second statement. for %i = 0 to 7 { %x = "foo"(%i) : (affineint) -> affineint "bar"(%x) : (affineint) -> affineint } PiperOrigin-RevId: 214975731
* Change loop step to be a positive integral constantUday Bondhugula2019-03-291-0/+1
| | | | | | Changing this per discussion on mlir-team. Spec updated. PiperOrigin-RevId: 214868483
* Add support to TF f32_ref type in MLIRFeng Liu2019-03-292-0/+5
| | | | PiperOrigin-RevId: 214722005
* Fix b/116749799, an issue where the ZeroResult trait's verifier hook left in ↵Chris Lattner2019-03-291-0/+52
| | | | | | | | | an old form. Upgrade it, and move all the trait verifier implementations consistently out of line to reduce template bloat. PiperOrigin-RevId: 214718242
* [MLIR] Add DimOp build supportNicolas Vasilache2019-03-291-0/+7
| | | | | | This CL introduces basic support to build a DimOp as well as a standalone test. PiperOrigin-RevId: 214688910
* Rename OpBase -> Op.Chris Lattner2019-03-292-7/+7
| | | | PiperOrigin-RevId: 214676460
* Introduce a new BinaryOp to commonize simple binary ops, introduce traits forChris Lattner2019-03-292-98/+102
| | | | | | | | | ResultIsFloatLike/ResultIsIntegerLike, move some code out of templates into shared code, keep the ops in StandardOps.cpp/h sorted. This significantly reduces the boilerplate for Add/Mul sorts of ops. In a subsequent patch, I plan to rename OpBase to Op, but didn't want to clutter this diff. PiperOrigin-RevId: 214622871
* [MLIR] Fix AsmPrinter for short-hand bound notationNicolas Vasilache2019-03-291-13/+18
| | | | | | | | | | | | | | | | | | | This CL retricts shorthand notation printing to only the bounds that can be roundtripped unambiguously; i.e.: 1. ()[]->(%some_cst) ()[] 2. ()[s0]->(s0) ()[%some_symbol] Upon inspection it turns out that the constant case was lossy so this CL also updates it. Note however that fixing this issue exhibits a potential issues in unroll.mlir. L488 exhibits a map ()[s0] -> (1)()[%arg0] which could be simplified down to ()[]->(1)()[]. This does not seem like a bug but maybe an undesired complexity in the maps generated by unrolling. bondhugula@, care to take a look? PiperOrigin-RevId: 214531410
* [MLIR] Add support for MulFOpNicolas Vasilache2019-03-291-1/+47
| | | | | | | | This CL adds support for `mulf` which is necessary to write/emit a simple scalar matmul in MLIR. This CL does not consider automation of generation of ops but mulf is important and useful enough to be added on its own atm. PiperOrigin-RevId: 214496098
* Adds constant folding hook for AffineApplyOp.MLIR Team2019-03-291-0/+85
| | | | PiperOrigin-RevId: 214287780
* [MLIR] Fix AsmPrinter.cpp for single ssa-id AffineMapNicolas Vasilache2019-03-291-3/+8
| | | | | | | | | | | | | | | | | | | | | | | The AsmPrinter wrongly assumes that all single ssa-id AffineMap are the identity map for the purpose of printing. This CL adds the missing level of indirection as well as a test. This bug was originally shaken off by the experimental TC->MLIR path. Before this CL, the test would print: ``` mlfunc @mlfuncsimplemap(%arg0 : affineint, %arg1 : affineint, %arg2 : affineint) { for %i0 = 0 to %arg0 { for %i1 = 0 to %i0 { ~~~ should be %arg1 %c42_i32 = constant 42 : i32 } } return } ``` PiperOrigin-RevId: 214120817
* Add op registry for registering MLIR ops.Jacques Pienaar2019-03-292-7/+22
| | | | | | Instead of linking in different initializeMLIRContext functions, add a registry mechanism and function to initialize all registered ops in a given MLIRContext. Initialize all registered ops along with the StandardOps when constructing a MLIRContext. PiperOrigin-RevId: 214073842
* Introduce [post]dominator tree and related infrastructure, use it in CFG funcChris Lattner2019-03-293-499/+23
| | | | | | | | | | | | | | | | verifier. We get most of this infrastructure directly from LLVM, we just need to adapt it to our CFG abstraction. This has a few unrelated changes engangled in it: - getFunction() in various classes was const incorrect, fix it. - This moves Verifier.cpp to the analysis library, since Verifier depends on dominance and these are both really analyses. - IndexedAccessorIterator::reference was defined wrong, leading to really exciting template errors that were fun to diagnose. - This flips the boolean sense of the foldOperation() function in constant folding pass in response to previous patch feedback. PiperOrigin-RevId: 214046593
* Supports TF Complex64/Complex128 types in the tf/mlir roundtrip pass.Feng Liu2019-03-292-0/+14
| | | | | | | | Alternatively, we can defined a TFComplexType with a width parameter in the mlir, then both types can be converted to the same mlir type with different width (like IntegerType). We chose to use a direct mapping because there are only two TF Complex types. PiperOrigin-RevId: 213856651
* Add verification for AllocOp.MLIR Team2019-03-291-15/+31
| | | | PiperOrigin-RevId: 213829386
* Implement support for constant folding operations and a simple constant foldingChris Lattner2019-03-292-6/+46
| | | | | | | | | | | | | | | | | | optimization pass: - Give the ability for operations to implement a constantFold hook (a simple one for single-result ops as well as general support for multi-result ops). - Implement folding support for constant and addf. - Implement support in AbstractOperation and Operation to make this usable by clients. - Implement a very simple constant folding pass that does top down folding on CFG and ML functions, with a testcase that exercises all the above stuff. Random cleanups: - Improve the build APIs for ConstantOp. - Stop passing "-o -" to mlir-opt in the testsuite, since that is the default. PiperOrigin-RevId: 213749809
* Support TF Variant type in the tf/mlir roundtrip pass.Feng Liu2019-03-293-8/+6
| | | | PiperOrigin-RevId: 213748573
* Handle the TF resource data type in the TF/XLA roundtrip pass.Feng Liu2019-03-293-1/+7
| | | | PiperOrigin-RevId: 213650346
* Add missing verifier logic for addf, and fix b/116054838 - Parser crash ↵Chris Lattner2019-03-291-4/+20
| | | | | | handling alloc with no affine mappings. PiperOrigin-RevId: 213639056
* Add function attributes for ExtFunction, CFGFunction and MLFunction.Feng Liu2019-03-292-50/+83
| | | | PiperOrigin-RevId: 213540509
* Extend loop unroll/unroll-and-jam to affine bounds + refactor related code.Uday Bondhugula2019-03-292-12/+22
| | | | | | | | | | | | | | | | | - extend loop unroll-jam similar to loop unroll for affine bounds - extend both loop unroll/unroll-jam to deal with cleanup loop for non multiple of unroll factor. - extend promotion of single iteration loops to work with affine bounds - fix typo bugs in loop unroll - refactor common code b/w loop unroll and loop unroll-jam - move prototypes of non-pass transforms to LoopUtils.h - add additional builder methods. - introduce loopUnrollUpTo(factor) to unroll by either factor or trip count, whichever is less. - remove Statement::isInnermost (not used for now - will come back at the right place/in right form later) PiperOrigin-RevId: 213471227
* Store 'then' clause statements directly in the 'if' statement.Tatiana Shpeisman2019-03-292-11/+7
| | | | | | Also a few minor changes. PiperOrigin-RevId: 213359024
* Misc changes to builder's and Transforms/ API to allow code generation.Uday Bondhugula2019-03-291-0/+5
| | | | | | | | | - add builder method for ReturnOp - expose API from Transforms/ to work on specific ML statements (do this for LoopUnroll, LoopUnrollAndJam) - add MLFuncBuilder::getForStmtBodyBuilder, ::getBlock PiperOrigin-RevId: 213074178
* Change unranked tensor syntax from tensor<??f32> to tensor<*xf32> perChris Lattner2019-03-291-1/+1
| | | | | | discussion on the list. PiperOrigin-RevId: 212838226
* Introduce pretty syntax for shape_cast as discussed on the list last week.Chris Lattner2019-03-291-0/+14
| | | | PiperOrigin-RevId: 212823681
* Add misc builder convenience methods for AffineMap's, for statement's.Uday Bondhugula2019-03-294-11/+62
| | | | | | | Use these methods to simplify existing code. Rename getConstantMap getConstantAffineMap. Move declarations to group similar ones together. PiperOrigin-RevId: 212814829
* Extend getConstantTripCount to deal with a larger subset of loop bounds; ↵Uday Bondhugula2019-03-295-54/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | make loop unroll/unroll-and-jam more powerful; add additional affine expr builder methods - use previously added analysis/simplification to infer multiple of unroll factor trip counts, making loop unroll/unroll-and-jam more general. - for loop unroll, support bounds that are single result affine map's with the same set of operands. For unknown loop bounds, loop unroll will now work as long as trip count can be determined to be a multiple of unroll factor. - extend getConstantTripCount to deal with single result affine map's with the same operands. move it to mlir/Analysis/LoopAnalysis.cpp - add additional builder utility methods for affine expr arithmetic (difference, mod/floordiv/ceildiv w.r.t postitive constant). simplify code to use the utility methods. - move affine analysis routines to AffineAnalysis.cpp/.h from AffineStructures.cpp/.h. - Rename LoopUnrollJam to LoopUnrollAndJam to match class name. - add an additional simplification for simplifyFloorDiv, simplifyCeilDiv - Rename AffineMap::getNumOperands() getNumInputs: an affine map by itself does not have operands. Operands are passed to it through affine_apply, from loop bounds/if condition's, etc., operands are stored in the latter. This should be sufficiently powerful for now as far as unroll/unroll-and-jam go for TPU code generation, and can move to other analyses/transformations. Loop nests like these are now unrolled without any cleanup loop being generated. for %i = 1 to 100 { // unroll factor 4: no cleanup loop will be generated. for %j = (d0) -> (d0) (%i) to (d0) -> (5*d0 + 3) (%i) { %x = "foo"(%j) : (affineint) -> i32 } } for %i = 1 to 100 { // unroll factor 4: no cleanup loop will be generated. for %j = (d0) -> (d0) (%i) to (d0) -> (d0 - d mod 4 - 1) (%i) { %y = "foo"(%j) : (affineint) -> i32 } } for %i = 1 to 100 { for %j = (d0) -> (d0) (%i) to (d0) -> (d0 + 128) (%i) { %x = "foo"() : () -> i32 } } TODO(bondhugula): extend this to LoopUnrollAndJam as well in the next CL (with minor changes). PiperOrigin-RevId: 212661212
* Fix cast in AffineMap::getSingleConstantValue and rename toUday Bondhugula2019-03-292-4/+4
| | | | | | getSingleConstantResult. PiperOrigin-RevId: 212544394
* rework the custom op verifier hooks to use the diagnostic emissionChris Lattner2019-03-295-89/+121
| | | | | | | | | | infrastructure, instead of returning a const char*. This allows custom formatting and more interesting diagnostics. This patch regresses the error message quality from the control flow lowering pass, I'll address this in a subsequent patch. PiperOrigin-RevId: 212210681
* Add utility to promote single iteration loops. Add methods for getting constantUday Bondhugula2019-03-291-0/+18
| | | | | | | | | | | loop counts. Improve / refactor loop unroll / loop unroll and jam. - add utility to remove single iteration loops. - use this utility to promote single iteration loops after unroll/unroll-and-jam - use loopUnrollByFactor for loopUnrollFull and remove most of the latter. - add methods for getting constant loop trip count PiperOrigin-RevId: 212039569
* Internal change.MLIR Team2019-03-291-1/+1
| | | | PiperOrigin-RevId: 212018532
* Add location specifier to MLIR Functions, and:Chris Lattner2019-03-292-67/+70
| | | | | | | | | | | - Compress the identifier/kind of a Function into a single word. - Eliminate otherFailure from verifier now that we always have a location - Eliminate the error string from the verifier now that we always have locations. - Simplify the parser's handling of fn forward references, using the location tracked by the function. PiperOrigin-RevId: 211985101
* Improve location reporting in the verifier for return instructions and otherChris Lattner2019-03-291-12/+25
| | | | | | | | | | | | | | | | | | | | | | | terminators. Improve mlir-opt to print better location info in the split-files case. Before: error: unexpected error: branch has 2 operands, but target block has 1 br bb1(%0tensorflow/mlir#1, %0tensorflow/mlir#0 : i17, i1) ^ after: invalid.mlir split at line tensorflow/mlir#305:6:3: error: unexpected error: branch has 2 operands, but target block has 1 br bb1(%0tensorflow/mlir#1, %0tensorflow/mlir#0 : i17, i1) ^ It still isn't optimal (it would be better to have just the original file and line number but is a step forward, and doing the optimal thing would be a lot more complicated. PiperOrigin-RevId: 211917067
* Teach RaiseControlFlow to handle IfOp's with partially infered shapes,Chris Lattner2019-03-291-1/+43
| | | | | | | | | | | | inserting shape_casts as necessary. Along the way: - Add some missing accessors to the AtLeastNOperands trait. - Implement shape_cast / ShapeCastOp standard op. - Improve handling of errors in mlir-opt, making it easier to understand errors when invalid IR is rejected by the verifier. PiperOrigin-RevId: 211897877
* Several minor infra improvements:Chris Lattner2019-03-292-59/+43
| | | | | | | | | | | | | | | - Make the tf-lower-control flow handle error cases better. Add a testcase that (currently) fails due to type mismatches. - Factor more code in the verifier for basic block argument checking, and check more invariants. - Fix a crasher in the asmprinter on null instructions (which only occurs on invalid code). - Fix a bug handling conditional branches with no block operands, it would access &operands[0] instead of using operands.data(). - Enhance the mlir-opt driver to use the verifier() in a non-crashing mode, allowing issues to be reported as diagnostics. PiperOrigin-RevId: 211818291
* Implement getFunction() helpers on the various value types, and use it toChris Lattner2019-03-292-3/+53
| | | | | | implement some simple checks in the Verifier. PiperOrigin-RevId: 211729987
OpenPOWER on IntegriCloud