[mlir] move SCF headers to SCF/{IR,Transforms} respectivelyThis aligns the SCF dialect file layout with the majority of the dialects.Reviewed By: jpienaarDifferential Revision: https://reviews.
[mlir] move SCF headers to SCF/{IR,Transforms} respectivelyThis aligns the SCF dialect file layout with the majority of the dialects.Reviewed By: jpienaarDifferential Revision: https://reviews.llvm.org/D128049
show more ...
[mlir] (NFC) Clean up bazel and CMake target namesAll dialect targets in bazel have been named *Dialect and all dialecttargets in CMake have been named MLIR*Dialect.
[mlir][math] Add math.ctlz expansion to control flow + arith operationsCtlz is an intrinsic in LLVM but does not have equivalent operations in SPIR-V.Including a decomposition gives an alternative
[mlir][math] Add math.ctlz expansion to control flow + arith operationsCtlz is an intrinsic in LLVM but does not have equivalent operations in SPIR-V.Including a decomposition gives an alternative path for these platforms.Reviewed By: NatashaKnkDifferential Revision: https://reviews.llvm.org/D126261
[mlir] Rework the implementation of TypeIDThis commit restructures how TypeID is implemented to ideally avoidthe current problems related to shared libraries. This is done by changingthe "implici
[mlir] Rework the implementation of TypeIDThis commit restructures how TypeID is implemented to ideally avoidthe current problems related to shared libraries. This is done by changingthe "implicit" fallback path to use the name of the type, instead of usinga static template variable (which breaks shared libraries). The major downside to thisis that it adds some additional initialization costs for the implicit path. Given theuse of type names for uniqueness in the fallback, we also no longer allow typesdefined in anonymous namespaces to have an implicit TypeID. To simplify definingan ID for these classes, a new `MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID` macrowas added to allow for explicitly defining a TypeID directly on an internal class.To help identify when types are using the fallback, `-debug-only=typeid` can beused to log which types are using implicit ids.This change generally only requires changes to the test passes, which are all definedin anonymous namespaces, and thus can't use the fallback any longer.Differential Revision: https://reviews.llvm.org/D122775
[mlir][test] Generalize a bunch of FuncOp based passes to run on any operation/interfacesA lot of test passes are currently anchored on FuncOp, but thisdependencyis generally just historical. A m
[mlir][test] Generalize a bunch of FuncOp based passes to run on any operation/interfacesA lot of test passes are currently anchored on FuncOp, but thisdependencyis generally just historical. A majority of these test passes can run onany operation, or can operate on a specific interface(FunctionOpInterface/SymbolOpInterface).This allows for greatly reducing the API dependency on FuncOp, whichis slated to be moved out of the Builtin dialect.Differential Revision: https://reviews.llvm.org/D121191
[mlir][vector][NFC] Split into IR, Transforms and UtilsThis reduces the dependencies of the MLIRVector target and makes the dialect consistent with other dialects.Differential Revision: https://r
[mlir][vector][NFC] Split into IR, Transforms and UtilsThis reduces the dependencies of the MLIRVector target and makes the dialect consistent with other dialects.Differential Revision: https://reviews.llvm.org/D118533
[mlir][Pass] Deprecate FunctionPass in favor of OperationPass<FuncOp>The only benefit of FunctionPass is that it filters out functiondeclarations. This isn't enough to justify carrying it around,
[mlir][Pass] Deprecate FunctionPass in favor of OperationPass<FuncOp>The only benefit of FunctionPass is that it filters out functiondeclarations. This isn't enough to justify carrying it around, as we cansimplify filter out declarations when necessary within the pass. We canalso explore with better scheduling primitives to filter out declarationsat the pipeline level in the future.The definition of FunctionPass is left intact for now to allow time for downstreamusers to migrate.Differential Revision: https://reviews.llvm.org/D117182
Apply clang-tidy fixes for bugprone-copy-constructor-init to MLIR (NFC)Reviewed By: rriddle, MogballDifferential Revision: https://reviews.llvm.org/D116245
Fix clang-tidy issues in mlir/ (NFC)Reviewed By: ftynseDifferential Revision: https://reviews.llvm.org/D115956
Adjust "end namespace" comment in MLIR to match new agree'd coding styleSee D115115 and this mailing list discussion:https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.htmlDifferenti
Adjust "end namespace" comment in MLIR to match new agree'd coding styleSee D115115 and this mailing list discussion:https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.htmlDifferential Revision: https://reviews.llvm.org/D115309
[mlir] Add polynomial approximation for vectorized math::RsqrtThis patch adds a polynomial approximation that matches theapproximation in Eigen.Note that the approximation only applies to vector
[mlir] Add polynomial approximation for vectorized math::RsqrtThis patch adds a polynomial approximation that matches theapproximation in Eigen.Note that the approximation only applies to vectorized inputs;the scalar rsqrt is left unmodified.The approximation is protected with a flag since it emits an AVX2intrinsic (generated via the X86Vector). This is the only reasonablyclean way that I could find to generate the exact approximation thatI wanted (i.e. an identical one to Eigen's).I considered two alternatives:1. Introduce a Rsqrt intrinsic in LLVM, which doesn't exist yet. I believe this is because there is no definition of Rsqrt that all backends could agree on, since hardware instructions that implement it have widely varying degrees of precision. This is something that the standard could mandate, but Rsqrt is not part of IEEE754, so I don't think this option is feasible.2. Emit fdiv(1.0, sqrt) with fast math flags to allow reciprocal transformations. Although portable, this doesn't allow us to generate exactly the code we want; it is the LLVM backend, and not MLIR, who controls what code is generated based on the target CPU.Reviewed By: ezhulenevDifferential Revision: https://reviews.llvm.org/D112192
[MLIR] Replace std ops with arith dialect opsPrecursor: https://reviews.llvm.org/D110200Removed redundant ops from the standard dialect that were moved to the`arith` or `math` dialects.Renamed
[MLIR] Replace std ops with arith dialect opsPrecursor: https://reviews.llvm.org/D110200Removed redundant ops from the standard dialect that were moved to the`arith` or `math` dialects.Renamed all instances of operations in the codebase and in tests.Reviewed By: rriddle, jpienaarDifferential Revision: https://reviews.llvm.org/D110797
[mlir] Remove unused header include.Also adjust BUILD.bazel and remove an unused dependency.Differential Revision: https://reviews.llvm.org/D108027
[mlir] Drop LLVM dialect from TestPolynomialApproximationNo longer needed after c1ebefdf77f34cc0b23597071098c8f8a8d2839b
Add missing cmake dep to fix MLIR build with BUILD_SHARED_LIBS=ON (NFC)
[mlir] Math: add algebraic simplification patterns to math transformsReviewed By: bkramerDifferential Revision: https://reviews.llvm.org/D106822
Migrate MLIR test passes to the new registration APIMake sure they all define getArgument()/getDescription().Depends On D104421Differential Revision: https://reviews.llvm.org/D104426
[mlir][NFC] Move passes in test/lib/Transforms/ to a directory that mirrors what they testtest/lib/Transforms/ has bitrot and become somewhat of a dumping grounds for testing pretty much any part o
[mlir][NFC] Move passes in test/lib/Transforms/ to a directory that mirrors what they testtest/lib/Transforms/ has bitrot and become somewhat of a dumping grounds for testing pretty much any part of the project. This revision cleans this up, and moves the files within to a directory that reflects what is actually being tested.Differential Revision: https://reviews.llvm.org/D102456