|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6 |
|
| #
8b68da2c |
| 17-Jun-2022 |
Alex Zinenko <[email protected]> |
[mlir] move SCF headers to SCF/{IR,Transforms} respectively
This aligns the SCF dialect file layout with the majority of the dialects.
Reviewed By: jpienaar
Differential Revision: https://reviews.
[mlir] move SCF headers to SCF/{IR,Transforms} respectively
This aligns the SCF dialect file layout with the majority of the dialects.
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D128049
show more ...
|
|
Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
| #
ceefc261 |
| 03-Apr-2022 |
Mehdi Amini <[email protected]> |
Apply clang-tidy fixes for llvm-qualified-auto in ConvertShapeConstraints.cpp (NFC)
|
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3 |
|
| #
47f175b0 |
| 07-Mar-2022 |
River Riddle <[email protected]> |
[mlir] Update FuncOp conversion passes to Pass/InterfacePass<FunctionOpInterface>
These passes generally don't rely on any special aspects of FuncOp, and moving allows for these passes to be used in
[mlir] Update FuncOp conversion passes to Pass/InterfacePass<FunctionOpInterface>
These passes generally don't rely on any special aspects of FuncOp, and moving allows for these passes to be used in many more situations. The passes that obviously weren't relying on invariants guaranteed by a "function" were updated to be generic pass, the rest were updated to be FunctionOpinterface InterfacePasses.
The test updates are NFC switching from implicit nesting (-pass -pass2) form to the -pass-pipeline form (generic passes do not implicitly nest as op-specific passes do).
Differential Revision: https://reviews.llvm.org/D121190
show more ...
|
|
Revision tags: llvmorg-14.0.0-rc2 |
|
| #
1f971e23 |
| 28-Feb-2022 |
River Riddle <[email protected]> |
[mlir] Trim a huge number of unnecessary dependencies on the Func dialect
The Func has a large number of legacy dependencies carried over from the old Standard dialect, which was pervasive and conta
[mlir] Trim a huge number of unnecessary dependencies on the Func dialect
The Func has a large number of legacy dependencies carried over from the old Standard dialect, which was pervasive and contained a large number of varied operations. With the split of the standard dialect and its demise, a lot of lingering dead dependencies have survived to the Func dialect. This commit removes a large majority of then, greatly reducing the dependence surface area of the Func dialect.
show more ...
|
| #
23aa5a74 |
| 26-Feb-2022 |
River Riddle <[email protected]> |
[mlir] Rename the Standard dialect to the Func dialect
The last remaining operations in the standard dialect all revolve around FuncOp/function related constructs. This patch simply handles the init
[mlir] Rename the Standard dialect to the Func dialect
The last remaining operations in the standard dialect all revolve around FuncOp/function related constructs. This patch simply handles the initial renaming (which by itself is already huge), but there are a large number of cleanups unlocked/necessary afterwards:
* Removing a bunch of unnecessary dependencies on Func * Cleaning up the From/ToStandard conversion passes * Preparing for the move of FuncOp to the Func dialect
See the discussion at https://discourse.llvm.org/t/standard-dialect-the-final-chapter/6061
Differential Revision: https://reviews.llvm.org/D120624
show more ...
|
|
Revision tags: llvmorg-14.0.0-rc1 |
|
| #
ace01605 |
| 04-Feb-2022 |
River Riddle <[email protected]> |
[mlir] Split out a new ControlFlow dialect from Standard
This dialect is intended to model lower level/branch based control-flow constructs. The initial set of operations are: AssertOp, BranchOp, Co
[mlir] Split out a new ControlFlow dialect from Standard
This dialect is intended to model lower level/branch based control-flow constructs. The initial set of operations are: AssertOp, BranchOp, CondBranchOp, SwitchOp; all split out from the current standard dialect.
See https://discourse.llvm.org/t/standard-dialect-the-final-chapter/6061
Differential Revision: https://reviews.llvm.org/D118966
show more ...
|
|
Revision tags: llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
| #
cfb72fd3 |
| 25-Oct-2021 |
Jacques Pienaar <[email protected]> |
[mlir] Switch arith, llvm, std & shape dialects to accessors prefixed both form.
Following https://llvm.discourse.group/t/psa-ods-generated-accessors-will-change-to-have-a-get-prefix-update-you-apis
[mlir] Switch arith, llvm, std & shape dialects to accessors prefixed both form.
Following https://llvm.discourse.group/t/psa-ods-generated-accessors-will-change-to-have-a-get-prefix-update-you-apis/4476, this follows flipping these dialects to _Both prefixed form. This changes the accessors to have a prefix. This was possibly mostly without breaking breaking changes if the existing convenience methods were used.
(https://github.com/jpienaar/llvm-project/blob/main/clang-tools-extra/clang-tidy/misc/AddGetterCheck.cpp was used to migrate the callers post flipping, using the output from Operator.cpp)
Differential Revision: https://reviews.llvm.org/D112383
show more ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
| #
dc4e913b |
| 22-Mar-2021 |
Chris Lattner <[email protected]> |
[PatternMatch] Big mechanical rename OwningRewritePatternList -> RewritePatternSet and insert -> add. NFC
This doesn't change APIs, this just cleans up the many in-tree uses of these names to use t
[PatternMatch] Big mechanical rename OwningRewritePatternList -> RewritePatternSet and insert -> add. NFC
This doesn't change APIs, this just cleans up the many in-tree uses of these names to use the new preferred names. We'll keep the old names around for a couple weeks to help transitions.
Differential Revision: https://reviews.llvm.org/D99127
show more ...
|
| #
3a506b31 |
| 20-Mar-2021 |
Chris Lattner <[email protected]> |
Change OwningRewritePatternList to carry an MLIRContext with it.
This updates the codebase to pass the context when creating an instance of OwningRewritePatternList, and starts removing extraneous M
Change OwningRewritePatternList to carry an MLIRContext with it.
This updates the codebase to pass the context when creating an instance of OwningRewritePatternList, and starts removing extraneous MLIRContext parameters. There are many many more to be removed.
Differential Revision: https://reviews.llvm.org/D99028
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc3 |
|
| #
73cb58dc |
| 01-Mar-2021 |
Benjamin Kramer <[email protected]> |
[mlir][Shape] Lower cstr_eq to shape_eq + assert
Differential Revision: https://reviews.llvm.org/D97860
|
|
Revision tags: llvmorg-12.0.0-rc2 |
|
| #
3842d4b6 |
| 10-Feb-2021 |
Tres Popp <[email protected]> |
Make shape.is_broadcastable/shape.cstr_broadcastable nary
This corresponds with the previous work to make shape.broadcast nary. Additionally, simplify the ConvertShapeConstraints pass. It now doesn'
Make shape.is_broadcastable/shape.cstr_broadcastable nary
This corresponds with the previous work to make shape.broadcast nary. Additionally, simplify the ConvertShapeConstraints pass. It now doesn't lower an implicit shape.is_broadcastable. This is still the same in combination with shape-to-standard when the 2 passes are used in either order.
Differential Revision: https://reviews.llvm.org/D96401
show more ...
|
|
Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2 |
|
| #
444822d7 |
| 11-Dec-2020 |
Sean Silva <[email protected]> |
Revert "Revert "[mlir] Start splitting the `tensor` dialect out of `std`.""
This reverts commit 0d48d265db6633e4e575f81f9d3a52139b1dc5ca.
This reapplies the following commit, with a fix for CAPI/ir
Revert "Revert "[mlir] Start splitting the `tensor` dialect out of `std`.""
This reverts commit 0d48d265db6633e4e575f81f9d3a52139b1dc5ca.
This reapplies the following commit, with a fix for CAPI/ir.c:
[mlir] Start splitting the `tensor` dialect out of `std`.
This starts by moving `std.extract_element` to `tensor.extract` (this mirrors the naming of `vector.extract`).
Curiously, `std.extract_element` supposedly works on vectors as well, and this patch removes that functionality. I would tend to do that in separate patch, but I couldn't find any downstream users relying on this, and the fact that we have `vector.extract` made it seem safe enough to lump in here.
This also sets up the `tensor` dialect as a dependency of the `std` dialect, as some ops that currently live in `std` depend on `tensor.extract` via their canonicalization patterns.
Part of RFC: https://llvm.discourse.group/t/rfc-split-the-tensor-dialect-from-std/2347/2
Differential Revision: https://reviews.llvm.org/D92991
show more ...
|
| #
0d48d265 |
| 11-Dec-2020 |
Sean Silva <[email protected]> |
Revert "[mlir] Start splitting the `tensor` dialect out of `std`."
This reverts commit cab8dda90f48e15ee94b0d55ceac5b6a812e4743.
I mistakenly thought that CAPI/ir.c failure was unrelated to this ch
Revert "[mlir] Start splitting the `tensor` dialect out of `std`."
This reverts commit cab8dda90f48e15ee94b0d55ceac5b6a812e4743.
I mistakenly thought that CAPI/ir.c failure was unrelated to this change. Need to debug it.
show more ...
|
| #
cab8dda9 |
| 10-Dec-2020 |
Sean Silva <[email protected]> |
[mlir] Start splitting the `tensor` dialect out of `std`.
This starts by moving `std.extract_element` to `tensor.extract` (this mirrors the naming of `vector.extract`).
Curiously, `std.extract_elem
[mlir] Start splitting the `tensor` dialect out of `std`.
This starts by moving `std.extract_element` to `tensor.extract` (this mirrors the naming of `vector.extract`).
Curiously, `std.extract_element` supposedly works on vectors as well, and this patch removes that functionality. I would tend to do that in separate patch, but I couldn't find any downstream users relying on this, and the fact that we have `vector.extract` made it seem safe enough to lump in here.
This also sets up the `tensor` dialect as a dependency of the `std` dialect, as some ops that currently live in `std` depend on `tensor.extract` via their canonicalization patterns.
Part of RFC: https://llvm.discourse.group/t/rfc-split-the-tensor-dialect-from-std/2347/2
Differential Revision: https://reviews.llvm.org/D92991
show more ...
|
|
Revision tags: llvmorg-11.0.1-rc1 |
|
| #
b6eb26fd |
| 27-Oct-2020 |
River Riddle <[email protected]> |
[mlir][NFC] Move around the code related to PatternRewriting to improve layering
There are several pieces of pattern rewriting infra in IR/ that really shouldn't be there. This revision moves those
[mlir][NFC] Move around the code related to PatternRewriting to improve layering
There are several pieces of pattern rewriting infra in IR/ that really shouldn't be there. This revision moves those pieces to a better location such that they are easier to evolve in the future(e.g. with PDL). More concretely this revision does the following:
* Create a Transforms/GreedyPatternRewriteDriver.h and move the apply*andFold methods there. The definitions for these methods are already in Transforms/ so it doesn't make sense for the declarations to be in IR.
* Create a new lib/Rewrite library and move PatternApplicator there. This new library will be focused on applying rewrites, and will also include compiling rewrites with PDL.
Differential Revision: https://reviews.llvm.org/D89103
show more ...
|
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4 |
|
| #
a975be0e |
| 24-Sep-2020 |
Sean Silva <[email protected]> |
[mlir][shape] Make conversion passes more consistent.
- use select-ops to make the lowering simpler - change style of FileCheck variables names to be consistent - change some variable names in the c
[mlir][shape] Make conversion passes more consistent.
- use select-ops to make the lowering simpler - change style of FileCheck variables names to be consistent - change some variable names in the code to be more explicit
Differential Revision: https://reviews.llvm.org/D88258
show more ...
|
| #
2d128b04 |
| 25-Sep-2020 |
Rahul Joshi <[email protected]> |
[NFC] Fix build warnings
|
|
Revision tags: llvmorg-11.0.0-rc3 |
|
| #
9ed1e587 |
| 18-Sep-2020 |
Sean Silva <[email protected]> |
[mlir][shape] Start a pass that lowers shape constraints.
This pass converts shape.cstr_* ops to eager (side-effecting) error-handling code. After that conversion is done, the witnesses are triviall
[mlir][shape] Start a pass that lowers shape constraints.
This pass converts shape.cstr_* ops to eager (side-effecting) error-handling code. After that conversion is done, the witnesses are trivially satisfied and are replaced with `shape.const_witness true`.
Differential Revision: https://reviews.llvm.org/D87941
show more ...
|