| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
Transforms/ by using the new diagnostic infrastructure.
--
PiperOrigin-RevId: 246955332
|
|
|
|
|
|
|
|
|
|
| |
and, transitively, access to the context.
This also fixes a bug where FunctionAttrs were not being remapped for function and function argument attributes.
--
PiperOrigin-RevId: 246876924
|
|
|
|
|
|
|
|
|
|
| |
caused by a bug in gcc versions < 7.0.
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56480)
--
PiperOrigin-RevId: 246664463
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 246614498
|
|
|
|
|
|
|
|
|
|
|
| |
Trying to activate both LLVM and MLIR passes in mlir-cpu-runner showed name collisions when registering pass names.
One possible way of disambiguating that should also work across dialects is to prepend the dialect name to the passes that specifically operate on that dialect.
With this CL, mlir-cpu-runner tests still run when both LLVM and MLIR passes are registered
--
PiperOrigin-RevId: 246539917
|
|
|
|
|
|
|
|
| |
division by zero
--
PiperOrigin-RevId: 246480710
|
|
|
|
|
|
|
|
| |
functionality needed to separate notes from remarks. It also provides a starting point to start building out better remark infrastructure.
--
PiperOrigin-RevId: 246175216
|
|
|
|
|
|
|
|
| |
'DiagnosticEngine' and move the diagnostic handler support and final diagnostic emission from the MLIRContext to it.
--
PiperOrigin-RevId: 246163897
|
|
|
|
|
|
|
|
|
|
|
| |
This CL implements the previously unsupported parsing for Range, View and Slice operations.
A pass is introduced to lower to the LLVM.
Tests are moved out of C++ land and into mlir/test/Examples.
This allows better fitting within standard developer workflows.
--
PiperOrigin-RevId: 245796600
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 244928036
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During the pattern rewrite, if the function is changed, i.e. ops created,
deleted or swapped, the pattern rewriter needs to re-scan the function entirely
and apply the patterns again, so the patterns whose root ops have been popped
out from the working list nor an immediate users of the changed ops can be
reconsidered.
A command line flag is added to set the max number of iterations rescanning the
function for pattern match. If the rewrite doesn' converge after this number,
this compiling will continue and the result can be sub-optimal.
One unit test is updated because this change fixed the missing optimization opportunities.
--
PiperOrigin-RevId: 244754190
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 244058051
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 244043679
|
|
|
|
|
|
|
|
|
| |
This addresses the compiler wraning of "comparison of unsigned expression
>= 0 is always true [-Wtype-limits]".
--
PiperOrigin-RevId: 242868703
|
|
|
|
|
|
|
|
|
| |
This addresses the "suggest parentheses around ‘&&’ within ‘||’
[-Wparentheses]" compiler warnings.
--
PiperOrigin-RevId: 242868670
|
|
|
|
|
|
|
|
| |
and into a reusable utility function (NFC).
--
PiperOrigin-RevId: 242716259
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 242679298
|
|
|
|
|
|
|
|
|
|
| |
matches the operation.
This is the same logic as the PatterRewriter.
--
PiperOrigin-RevId: 242287241
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
isa_nonnull
* dyn_cast_or_null
- This will first check if the operation is null before trying to 'dyn_cast':
Value *v = ...;
if (auto forOp = dyn_cast_or_null<AffineForOp>(v->getDefiningOp()))
...
* isa_nonnull
- This will first check if the pointer is null before trying to 'isa':
Value *v = ...;
if (isa_nonnull<AffineForOp>(v->getDefiningOp());
...
--
PiperOrigin-RevId: 242171343
|
|
|
|
|
|
|
|
| |
added
--
PiperOrigin-RevId: 242123122
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 242101364
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 242031201
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 242019230
|
|
|
|
|
|
|
|
|
|
| |
remove the need for ConstantFoldHelper to have a flag for insertion at the head of the entry block. This also fixes an asan bug in TestConstantFold due to the iteration order of operations and ConstantFoldHelper's constant insertion placement.
Note: This now means that we cannot fold chains of operations, i.e. where constant foldable operations feed into each other. Given that this is a testing pass solely for constant folding, this isn't really something that we want anyways. Constant fold tests should be simple and direct, with more advanced folding/feeding being tested with the canonicalizer.
--
PiperOrigin-RevId: 242011744
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 241994767
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GreedyPatternRewriteDriver
There are two places containing constant folding logic right now: the ConstantFold
pass and the GreedyPatternRewriteDriver. The logic was not shared and started to
drift apart. We were testing constant folding logic using the ConstantFold pass,
but lagged behind the GreedyPatternRewriteDriver, where we really want the constant
folding to happen.
This CL pulled the logic into utility functions and classes for sharing between
these two places. A new ConstantFoldHelper class is created to help constant fold
and de-duplication.
Also, renamed the ConstantFold pass to TestConstantFold to make it clear that it is
intended for testing purpose.
--
PiperOrigin-RevId: 241971681
|
|
|
|
|
|
|
|
| |
and rename walkPostOrder to walk.
--
PiperOrigin-RevId: 241965239
|
|
|
|
|
|
|
|
| |
not handle symbol operands correctly.
--
PiperOrigin-RevId: 241958502
|
|
|
|
|
|
|
|
|
| |
This CL fixes the non-determinism across compilers in an edsc::select expression used in LowerVectorTransfers. This is achieved by factoring the expression out of the function call to ensure a deterministic order of evaluation.
Since the expression is now factored out, fewer IR is generated and the test is updated accordingly.
--
PiperOrigin-RevId: 241679962
|
|
|
|
|
|
|
|
| |
bool. This also changes the return of Operation::emitError/emitOpError to LogicalResult as well.
--
PiperOrigin-RevId: 241588075
|
|
|
|
|
|
|
|
| |
region matches producer write region.
--
PiperOrigin-RevId: 241517207
|
|
|
|
|
|
|
|
| |
RewritePattern instead.
--
PiperOrigin-RevId: 241455472
|
|
|
|
|
|
|
|
|
| |
This is making up for some differences in standard library and linker flags.
It also get rid of the requirement to build with RTTI.
--
PiperOrigin-RevId: 241348845
|
|
|
|
|
|
|
|
|
| |
* Add initial version of build files;
* Update README with instructions to download and build MLIR from github;
--
PiperOrigin-RevId: 241102092
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On the read side,
```
%3 = vector_transfer_read %arg0, %i2, %i1, %i0 {permutation_map: (d0, d1, d2)->(d2, d0)} : (memref<?x?x?xf32>, index, index, index) -> vector<32x256xf32>
```
becomes:
```
%3 = vector_transfer_read %arg0[%i2, %i1, %i0] {permutation_map: (d0, d1, d2)->(d2, d0)} : memref<?x?x?xf32>, vector<32x256xf32>
```
On the write side,
```
vector_transfer_write %0, %arg0, %c3, %c3 {permutation_map: (d0, d1)->(d0)} : vector<128xf32>, memref<?x?xf32>, index, index
```
becomes
```
vector_transfer_write %0, %arg0[%c3, %c3] {permutation_map: (d0, d1)->(d0)} : vector<128xf32>, memref<?x?xf32>
```
Documentation will be cleaned up in a followup commit that also extracts a proper .md from the top of the file comments.
PiperOrigin-RevId: 241021879
|
|
|
|
|
|
|
| |
This CL allows the programmatic control of the target hardware vector size when creating a MaterializeVectorsPass.
This is useful for registering passes for the tutorial.
PiperOrigin-RevId: 240996136
|
|
|
|
|
|
|
|
|
|
| |
This CL removes the reliance of the vectorize pass on the specification of a `fastestVaryingDim` parameter. This parameter is a restriction meant to more easily target a particular loop/memref combination for vectorization and is mainly used for testing.
This also had the side-effect of restricting vectorization patterns to only the ones in which all memrefs were contiguous along the same loop dimension. This simple restriction prevented matmul to vectorize in 2-D.
this CL removes the restriction and adds the matmul test which vectorizes in 2-D along the parallel loops. Support for reduction loops is left for future work.
PiperOrigin-RevId: 240993827
|
|
|
|
|
|
| |
(takes care of a TODO, enables another tutorial test case).
PiperOrigin-RevId: 240979894
|
|
|
|
|
|
| |
llvm::outs. This allows for the output to be deterministic when multi-threading is enabled.
PiperOrigin-RevId: 240905858
|
|
|
|
| |
PiperOrigin-RevId: 240875432
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dialect conversion currently clones the operations that did not match any
pattern. This includes cloning any regions that belong to these operations.
Instead, apply conversion recursively to the nested regions.
Note that if an operation matched one of the conversion patterns, it is up to
the pattern rewriter to fill in the regions of the converted operation. This
may require calling back to the converter and is left for future work.
PiperOrigin-RevId: 240872410
|
|
|
|
|
|
| |
tutorial example).
PiperOrigin-RevId: 240859227
|
|
|
|
| |
PiperOrigin-RevId: 240814651
|
|
|
|
|
|
| |
Now that we have a dependence analysis, we can check that loops are indeed parallel and make vectorization correct.
PiperOrigin-RevId: 240682727
|
|
|
|
|
|
|
| |
This CL allows vectorization to be called and configured in other ways than just via command line arguments.
This allows triggering vectorization programmatically.
PiperOrigin-RevId: 240638208
|
|
|
|
| |
PiperOrigin-RevId: 240636130
|
|
|
|
|
|
| |
The Pass base class is providing a convenience getContext() accessor.
PiperOrigin-RevId: 240634961
|
|
|
|
| |
PiperOrigin-RevId: 240628260
|
|
|
|
| |
PiperOrigin-RevId: 240569775
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to legacy reasons (ML/CFG function separation), regions in affine control
flow operations require contained blocks not to have terminators. This is
inconsistent with the notion of the block and may complicate code motion
between regions of affine control operations and other regions.
Introduce `affine.terminator`, a special terminator operation that must be used
to terminate blocks inside affine operations and transfers the control back to
he region enclosing the affine operation. For brevity and readability reasons,
allow `affine.for` and `affine.if` to omit the `affine.terminator` in their
regions when using custom printing and parsing format. The custom parser
injects the `affine.terminator` if it is missing so as to always have it
present in constructed operations.
Update transformations to account for the presence of terminator. In
particular, most code motion transformation between loops should leave the
terminator in place, and code motion between loops and non-affine blocks should
drop the terminator.
PiperOrigin-RevId: 240536998
|