#
d1866f89 |
| 18-May-2020 |
Pierre Oechsel <pierre.oechsel@gmail.com> |
[MLIR] [Linalg] Add option to use the partial view after promotion.
For now the promoted buffer is indexed using the `full view`. The full view might be slightly bigger than the partial view (which
[MLIR] [Linalg] Add option to use the partial view after promotion.
For now the promoted buffer is indexed using the `full view`. The full view might be slightly bigger than the partial view (which is accounting for boundaries). Unfortunately this does not compose easily with other transformations when multiple buffers with shapes related to each other are involved. Take `linalg.matmul A B C` (with A of size MxK, B of size KxN and C of size MxN) and suppose we are: - Tiling over M by 100 - Promoting A only
This is producing a `linalg.matmul promoted_A B subview_C` where `promoted_A` is a promoted buffer of `A` of size (100xK) and `subview_C` is a subview of size mxK where m could be smaller than 100 due to boundaries thus leading to a possible incorrect behavior.
We propose to: - Add a new parameter to the tiling promotion allowing to enable the use of the full tile buffer. - By default all promoted buffers will be indexed by the partial view.
Note that this could be considered as a breaking change in comparison to the way the tiling promotion was working.
Differential Revision: https://reviews.llvm.org/D79927
show more ...
|
#
e0b99a5d |
| 13-May-2020 |
Nicolas Vasilache <ntv@google.com> |
[mlir] Add SubViewOp::getOrCreateRanges and fix folding pattern
The existing implementation of SubViewOp::getRanges relies on all offsets/sizes/strides to be dynamic values and does not work in comb
[mlir] Add SubViewOp::getOrCreateRanges and fix folding pattern
The existing implementation of SubViewOp::getRanges relies on all offsets/sizes/strides to be dynamic values and does not work in combination with canonicalization. This revision adds a SubViewOp::getOrCreateRanges to create the missing constants in the canonicalized case.
This allows reactivating the fused pass with staged pattern applications.
However another issue surfaces that the SubViewOp verifier is now too strict to allow folding. The existing folding pattern is turned into a canonicalization pattern which rewrites memref_cast + subview into subview + memref_cast.
The transform-patterns-matmul-to-vector can then be reactivated.
Differential Revision: https://reviews.llvm.org/D79759
show more ...
|
#
98eead81 |
| 10-May-2020 |
Sean Silva <silvasean@google.com> |
[mlir][Value] Add v.getDefiningOp<OpTy>()
Summary: This makes a common pattern of `dyn_cast_or_null<OpTy>(v.getDefiningOp())` more concise.
Differential Revision: https://reviews.llvm.org/D79681
|
#
6ed61a26 |
| 11-May-2020 |
Nicolas Vasilache <ntv@google.com> |
[mlir] Simplify and better document std.view semantics
This [discussion](https://llvm.discourse.group/t/viewop-isnt-expressive-enough/991/2) raised some concerns with ViewOp.
In particular, the han
[mlir] Simplify and better document std.view semantics
This [discussion](https://llvm.discourse.group/t/viewop-isnt-expressive-enough/991/2) raised some concerns with ViewOp.
In particular, the handling of offsets is incorrect and does not match the op description. Note that with an elemental type change, offsets cannot be part of the type in general because sizeof(srcType) != sizeof(dstType).
Howerver, offset is a poorly chosen term for this purpose and is renamed to byte_shift.
Additionally, for all intended purposes, trying to support non-identity layouts for this op does not bring expressive power but rather increases code complexity.
This revision simplifies the existing semantics and implementation. This simplification effort is voluntarily restrictive and acts as a stepping stone towards supporting richer semantics: treat the non-common cases as YAGNI for now and reevaluate based on concrete use cases once a round of simplification occurred.
Differential revision: https://reviews.llvm.org/D79541
show more ...
|
#
8dbbb223 |
| 11-May-2020 |
Nicolas Vasilache <ntv@google.com> |
[mlir][Linalg] NFC - Refactor and simplify Promotion
Summary: This revision introduces LinalgPromotionOptions to more easily control the application of promotion patterns. It also simplifies the dif
[mlir][Linalg] NFC - Refactor and simplify Promotion
Summary: This revision introduces LinalgPromotionOptions to more easily control the application of promotion patterns. It also simplifies the different entry points into Promotion in preparation for some behavior change in subsequent revisions.
Differential Revision: https://reviews.llvm.org/D79489
show more ...
|
#
c25b20c0 |
| 11-May-2020 |
Alex Zinenko <zinenko@google.com> |
[mlir] NFC: Rename LoopOps dialect to SCF (Structured Control Flow)
This dialect contains various structured control flow operaitons, not only loops, reflect this in the name. Drop the Ops suffix fo
[mlir] NFC: Rename LoopOps dialect to SCF (Structured Control Flow)
This dialect contains various structured control flow operaitons, not only loops, reflect this in the name. Drop the Ops suffix for consistency with other dialects.
Note that this only moves the files and changes the C++ namespace from 'loop' to 'scf'. The visible IR prefix remains the same and will be updated separately. The conversions will also be updated separately.
Differential Revision: https://reviews.llvm.org/D79578
show more ...
|
#
307cfdf5 |
| 02-May-2020 |
Nicolas Vasilache <ntv@google.com> |
[mlir][Linalg] Mostly NFC - Refactor Linalg patterns and transformations.
Linalg transformations are currently exposed as DRRs. Unfortunately RewriterGen does not play well with the line of work on
[mlir][Linalg] Mostly NFC - Refactor Linalg patterns and transformations.
Linalg transformations are currently exposed as DRRs. Unfortunately RewriterGen does not play well with the line of work on named linalg ops which require variadic operands and results. Additionally, DRR is arguably not the right abstraction to expose compositions of such patterns that don't rely on SSA use-def semantics.
This revision abandons DRRs and exposes manually written C++ patterns.
Refactorings and cleanups are performed to uniformize APIs. This refactoring will allow replacing the currently manually specified Linalg named ops.
A collateral victim of this refactoring is the `tileAndFuse` DRR, and the one associated test, which will be revived at a later time.
Lastly, the following 2 tests do not add value and are altered: - a dot_perm tile + interchange test does not test anything new and is removed - a dot tile + lower to loops does not need 2-D tiling and is trimmed.
show more ...
|
#
367229e1 |
| 23-Apr-2020 |
Nicolas Vasilache <ntv@google.com> |
[mlir][EDSC] Retire ValueHandle
The EDSC discussion [thread](https://llvm.discourse.group/t/evolving-builder-apis-based-on-lessons-learned-from-edsc/879) points out that ValueHandle has become an un
[mlir][EDSC] Retire ValueHandle
The EDSC discussion [thread](https://llvm.discourse.group/t/evolving-builder-apis-based-on-lessons-learned-from-edsc/879) points out that ValueHandle has become an unnecessary level of abstraction since MLIR switch from `Value *` to `Value` everywhere.
This revision removes this level of indirection.
show more ...
|
#
128d7275 |
| 21-Apr-2020 |
Pierre Oechsel <pierre.oechsel@gmail.com> |
[mlir] [linalg] Specify alignment during promotion.
The buffer allocated by a promotion can be subject to other transformations afterward. For example it could be vectorized, in which case it is nee
[mlir] [linalg] Specify alignment during promotion.
The buffer allocated by a promotion can be subject to other transformations afterward. For example it could be vectorized, in which case it is needed to ensure that this buffer is memory-aligned.
Differential Revision: https://reviews.llvm.org/D78556
show more ...
|
#
40d139c6 |
| 16-Apr-2020 |
Nicolas Vasilache <ntv@google.com> |
[mlir][Linalg] NFC - Split out EDSCs that require a Folder
Summary: This is an NFC cleanup in preparation for end-to-end named Linalg ops.
Differential Revision: https://reviews.llvm.org/D78331
|
#
92f1562f |
| 14-Apr-2020 |
River Riddle <riddleriver@gmail.com> |
[mlir][NFC] Remove the STLExtras.h header file now that it has been merged into LLVM.
Now that no more utilities exist within, this file can be deleted.
Differential Revision: https://reviews.llvm.
[mlir][NFC] Remove the STLExtras.h header file now that it has been merged into LLVM.
Now that no more utilities exist within, this file can be deleted.
Differential Revision: https://reviews.llvm.org/D78079
show more ...
|
#
3cb1f35d |
| 08-Apr-2020 |
Nicolas Vasilache <ntv@google.com> |
[mlir][Linalg] Use subview instead of linalg.slice in Promotion.cpp
This revision removes the reliance of Promotion on `linalg.slice` which is meant for the rank-reducing case.
Differential Revisio
[mlir][Linalg] Use subview instead of linalg.slice in Promotion.cpp
This revision removes the reliance of Promotion on `linalg.slice` which is meant for the rank-reducing case.
Differential Revision: https://reviews.llvm.org/D77676
show more ...
|
#
1834ad4a |
| 07-Apr-2020 |
River Riddle <riddleriver@gmail.com> |
[mlir][Pass] Update the PassGen to generate base classes instead of utilities
Summary: This is much cleaner, and fits the same structure as many other tablegen backends. This was not done originally
[mlir][Pass] Update the PassGen to generate base classes instead of utilities
Summary: This is much cleaner, and fits the same structure as many other tablegen backends. This was not done originally as the CRTP in the pass classes made it overly verbose/complex.
Differential Revision: https://reviews.llvm.org/D77367
show more ...
|
#
80aca1ea |
| 07-Apr-2020 |
River Riddle <riddleriver@gmail.com> |
[mlir][Pass] Remove the use of CRTP from the Pass classes
This revision removes all of the CRTP from the pass hierarchy in preparation for using the tablegen backend instead. This creates a much cle
[mlir][Pass] Remove the use of CRTP from the Pass classes
This revision removes all of the CRTP from the pass hierarchy in preparation for using the tablegen backend instead. This creates a much cleaner interface in the C++ code, and naturally fits with the rest of the infrastructure. A new utility class, PassWrapper, is added to replicate the existing behavior for passes not suitable for using the tablegen backend.
Differential Revision: https://reviews.llvm.org/D77350
show more ...
|
#
9a277af2 |
| 01-Apr-2020 |
River Riddle <riddleriver@gmail.com> |
[mlir][Pass] Add support for generating pass utilities via tablegen
This revision adds support for generating utilities for passes such as options/statistics/etc. that can be inferred from the table
[mlir][Pass] Add support for generating pass utilities via tablegen
This revision adds support for generating utilities for passes such as options/statistics/etc. that can be inferred from the tablegen definition. This removes additional boilerplate from the pass, and also makes it easier to remove the reliance on the pass registry to provide certain things(e.g. the pass argument).
Differential Revision: https://reviews.llvm.org/D76659
show more ...
|
#
e3d834a5 |
| 01-Apr-2020 |
River Riddle <riddleriver@gmail.com> |
[mlir][Pass] Move the registration of dialect passes to tablegen
This generates a Passes.td for all of the dialects that have transformation passes. This removes the need for global registration for
[mlir][Pass] Move the registration of dialect passes to tablegen
This generates a Passes.td for all of the dialects that have transformation passes. This removes the need for global registration for all of the dialect passes.
Differential Revision: https://reviews.llvm.org/D76657
show more ...
|
#
e9482ed1 |
| 21-Mar-2020 |
River Riddle <riddleriver@gmail.com> |
[mlir] Move several static cl::opts to be pass options instead.
This removes the reliance on global options, and also simplifies the pass registration.
Differential Revision: https://reviews.llvm.o
[mlir] Move several static cl::opts to be pass options instead.
This removes the reliance on global options, and also simplifies the pass registration.
Differential Revision: https://reviews.llvm.org/D76552
show more ...
|
#
e7084713 |
| 20-Mar-2020 |
Rob Suderman <suderman@google.com> |
[mlir][NFC] Cleanup AffineOps directory structure
Summary: Change AffineOps Dialect structure to better group both IR and Tranforms. This included extracting transforms directly related to AffineOps
[mlir][NFC] Cleanup AffineOps directory structure
Summary: Change AffineOps Dialect structure to better group both IR and Tranforms. This included extracting transforms directly related to AffineOps. Also move AffineOps to Affine.
Differential Revision: https://reviews.llvm.org/D76161
show more ...
|
#
92f7e813 |
| 13-Mar-2020 |
Hanhan Wang <hanchung@google.com> |
[mlir][Linalg] Implement padding for linalg.conv and lowering to loops.
Summary: To enable this, two changes are needed: 1) Add an optional attribute `padding` to linalg.conv. 2) Compute if the indi
[mlir][Linalg] Implement padding for linalg.conv and lowering to loops.
Summary: To enable this, two changes are needed: 1) Add an optional attribute `padding` to linalg.conv. 2) Compute if the indices accessing is out of bound in the loops. If so, use the padding value `0`. Otherwise, use the value derived from load.
In the patch, the padding only works for lowering without other transformations, e.g., tiling, fusion, etc.
Differential Revision: https://reviews.llvm.org/D75722
show more ...
|
#
35b68527 |
| 10-Jan-2020 |
Lei Zhang <antiagainst@google.com> |
[mlir] Add a signedness semantics bit to IntegerType
Thus far IntegerType has been signless: a value of IntegerType does not have a sign intrinsically and it's up to the specific operation to decide
[mlir] Add a signedness semantics bit to IntegerType
Thus far IntegerType has been signless: a value of IntegerType does not have a sign intrinsically and it's up to the specific operation to decide how to interpret those bits. For example, std.addi does two's complement arithmetic, and std.divis/std.diviu treats the first bit as a sign.
This design choice was made some time ago when we did't have lots of dialects and dialects were more rigid. Today we have much more extensible infrastructure and different dialect may want different modelling over integer signedness. So while we can say we want signless integers in the standard dialect, we cannot dictate for others. Requiring each dialect to model the signedness semantics with another set of custom types is duplicating the functionality everywhere, considering the fundamental role integer types play.
This CL extends the IntegerType with a signedness semantics bit. This gives each dialect an option to opt in signedness semantics if that's what they want and helps code sharing. The parser is modified to recognize `si[1-9][0-9]*` and `ui[1-9][0-9]*` as signed and unsigned integer types, respectively, leaving the original `i[1-9][0-9]*` to continue to mean no indication over signedness semantics. All existing dialects are not affected (yet) as this is a feature to opt in.
More discussions can be found at:
https://groups.google.com/a/tensorflow.org/d/msg/mlir/XmkV8HOPWpo/7O4X0Nb_AQAJ
Differential Revision: https://reviews.llvm.org/D72533
show more ...
|
#
0acd7e02 |
| 17-Feb-2020 |
Pierre Oechsel <pierre.oechsel@gmail.com> |
[mlir] Linalg: Extend promotion to non f32 buffers.
Summary: Linalg's promotion pass was only supporting f32 buffers due to how the zero value was build for the `fill` operation.
Moreover, `promote
[mlir] Linalg: Extend promotion to non f32 buffers.
Summary: Linalg's promotion pass was only supporting f32 buffers due to how the zero value was build for the `fill` operation.
Moreover, `promoteSubViewOperands` was returning a vector with one entry per float subview while omitting integer subviews. For a program with only integer subviews the return vector would be of size 0. However, `promoteSubViewsOperands` would try to access a non zero number of entries of this vector, resulting in a sefgault.
Reviewers: nicolasvasilache, ftynse
Reviewed By: ftynse
Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74532
show more ...
|
#
75394e13 |
| 10-Feb-2020 |
Nicolas Vasilache <ntv@google.com> |
[mlir][EDSC] Almost NFC - Refactor and untangle EDSC dependencies
This CL refactors EDSCs to layer them better and break unnecessary dependencies. After this refactoring, the top-level EDSC target o
[mlir][EDSC] Almost NFC - Refactor and untangle EDSC dependencies
This CL refactors EDSCs to layer them better and break unnecessary dependencies. After this refactoring, the top-level EDSC target only depends on IR but not on Dialects anymore and each dialect has its own EDSC directory.
This simplifies the layering and breaks cyclic dependencies. In particular, the declarative builder + folder are made explicit and are now confined to Linalg.
As the refactoring occurred, certain classes and abstractions that were not paying for themselves have been removed.
Differential Revision: https://reviews.llvm.org/D74302
show more ...
|
#
74df89f6 |
| 27-Jan-2020 |
Kern Handa <kern.handa@gmail.com> |
[NFC][mlir][linalg] Merge Utils/Intrinsics.h into EDSC/Intrinsics.h
Differential Revision: https://reviews.llvm.org/D73377
|
#
30857107 |
| 26-Jan-2020 |
Mehdi Amini <aminim@google.com> |
Mass update the MLIR license header to mention "Part of the LLVM project"
This is an artifact from merging MLIR into LLVM, the file headers are now aligned with the rest of the project.
|
#
7741de94 |
| 15-Jan-2020 |
Nicolas Vasilache <ntv@google.com> |
[mlir][Linalg] NFC - Cleanup Linalg Pass locations and namespacing
Summary: This diff moves the conversion pass declaration closer to its definition and makes the namespacing of passes consistent wi
[mlir][Linalg] NFC - Cleanup Linalg Pass locations and namespacing
Summary: This diff moves the conversion pass declaration closer to its definition and makes the namespacing of passes consistent with the rest of the infrastructure (i.e. `mlir::linalg::createXXXPass` -> `mlir::createXXXPass`).
Reviewers: ftynse, jpienaar, mehdi_amini
Subscribers: rriddle, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72766
show more ...
|