[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] Change ComplexToLLVM to be a generic passIt is currently a module pass, but shouldn't be. All of the patternsare local conversions, and don't require anything aboutfunctions/modules.Diff
[mlir] Change ComplexToLLVM to be a generic passIt is currently a module pass, but shouldn't be. All of the patternsare local conversions, and don't require anything aboutfunctions/modules.Differential Revision: https://reviews.llvm.org/D121192
show more ...
[mlir] Trim a huge number of unnecessary dependencies on the Func dialectThe Func has a large number of legacy dependencies carried over from the oldStandard dialect, which was pervasive and conta
[mlir] Trim a huge number of unnecessary dependencies on the Func dialectThe Func has a large number of legacy dependencies carried over from the oldStandard dialect, which was pervasive and contained a large number of variedoperations. With the split of the standard dialect and its demise, a lot of lingeringdead dependencies have survived to the Func dialect. This commit removes alarge majority of then, greatly reducing the dependence surface area of theFunc dialect.
[mlir] Rename the Standard dialect to the Func dialectThe last remaining operations in the standard dialect all revolve aroundFuncOp/function related constructs. This patch simply handles the init
[mlir] Rename the Standard dialect to the Func dialectThe last remaining operations in the standard dialect all revolve aroundFuncOp/function related constructs. This patch simply handles the initialrenaming (which by itself is already huge), but there are a large numberof 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 dialectSee the discussion at https://discourse.llvm.org/t/standard-dialect-the-final-chapter/6061Differential Revision: https://reviews.llvm.org/D120624
[mlir][complex] Lower complex.constant to LLVMThis fixes a regression from 480cd4cb8560532e544fc0c234749912dde759c6Differential Revision: https://reviews.llvm.org/D118347
[mlir] Switching accessors to prefixed form (NFC)Makes eventual prefixing flag flip smaller change.
[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:OpConversion] Remove the remaing usages of the deprecated matchAndRewrite methodsThis commits updates the remaining usages of the ArrayRef<Value> basedmatchAndRewrite/rewrite methods in favo
[mlir:OpConversion] Remove the remaing usages of the deprecated matchAndRewrite methodsThis commits updates the remaining usages of the ArrayRef<Value> basedmatchAndRewrite/rewrite methods in favor of the new OpAdaptoroverload.Differential Revision: https://reviews.llvm.org/D110360
[mlir] replace llvm.mlir.cast with unrealized_conversion_castThe dialect-specific cast between builtin (ex-standard) types and LLVMdialect types was introduced long time before built-in support fo
[mlir] replace llvm.mlir.cast with unrealized_conversion_castThe dialect-specific cast between builtin (ex-standard) types and LLVMdialect types was introduced long time before built-in support forunrealized_conversion_cast. It has a similar purpose, but is restrictedto compatible builtin and LLVM dialect types, which may hamperprogressive lowering and composition with types from other dialects.Replace llvm.mlir.cast with unrealized_conversion_cast, and drop theoperation that became unnecessary.Also make unrealized_conversion_cast legal by default inLLVMConversionTarget as the majority of convesions using it are partialconversions that actually want the casts to persist in the IR. Thestandard-to-llvm conversion, which is still expected to run last, cleansup the remaining casts standard-to-llvm conversion, which is stillexpected to run last, cleans up the remaining castsReviewed By: nicolasvasilacheDifferential Revision: https://reviews.llvm.org/D105880
[mlir] factor memref-to-llvm lowering out of std-to-llvmAfter the MemRef has been split out of the Standard dialect, theconversion to the LLVM dialect remained as a huge monolithic pass.This is u
[mlir] factor memref-to-llvm lowering out of std-to-llvmAfter the MemRef has been split out of the Standard dialect, theconversion to the LLVM dialect remained as a huge monolithic pass.This is undesirable for the same complexity management reasons as havinga huge Standard dialect itself, and is even more confusing given theexistence of a separate dialect. Extract the conversion of the MemRefdialect operations to LLVM into a separate library and a separateconversion pass.Reviewed By: herhut, silvasDifferential Revision: https://reviews.llvm.org/D105625
[mlir] factor out common parts of the converstion to the LLVM dialect"Standard-to-LLVM" conversion is one of the oldest passes in existence. It hasbecome quite large due to the size of the Standar
[mlir] factor out common parts of the converstion to the LLVM dialect"Standard-to-LLVM" conversion is one of the oldest passes in existence. It hasbecome quite large due to the size of the Standard dialect itself, which isbeing split into multiple smaller dialects. Furthermore, several conversionfeatures are useful for any dialect that is being converted to the LLVMdialect, which, without this refactoring, creates a dependency from thoseconversions to the "standard-to-llvm" one.Put several of the reusable utilities from this conversion to a separatelibrary, namely:- type converter from builtin to LLVM dialect types;- utility for building and accessing values of LLVM structure type;- utility for building and accessing values that represent memref in the LLVM dialect;- lowering options applicable everywhere.Additionally, remove the type wrapping/unwrapping notion from the typeconverter that is no longer relevant since LLVM types has been reimplemented asfirst-class MLIR types.Reviewed By: pifon2aDifferential Revision: https://reviews.llvm.org/D105534
[PatternMatch] Big mechanical rename OwningRewritePatternList -> RewritePatternSet and insert -> add. NFCThis doesn't change APIs, this just cleans up the many in-tree uses of thesenames to use t
[PatternMatch] Big mechanical rename OwningRewritePatternList -> RewritePatternSet and insert -> add. NFCThis doesn't change APIs, this just cleans up the many in-tree uses of thesenames to use the new preferred names. We'll keep the old names around for acouple weeks to help transitions.Differential Revision: https://reviews.llvm.org/D99127
Change OwningRewritePatternList to carry an MLIRContext with it.This updates the codebase to pass the context when creating an instance ofOwningRewritePatternList, 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 ofOwningRewritePatternList, and starts removing extraneous MLIRContextparameters. There are many many more to be removed.Differential Revision: https://reviews.llvm.org/D99028
Move LLVM::FMFAttr definition to TableGen (NFC)This is using the new Attribute storage generation support inTableGen to define the LLVM FastMathFlags.Differential Revision: https://reviews.llvm.
Move LLVM::FMFAttr definition to TableGen (NFC)This is using the new Attribute storage generation support inTableGen to define the LLVM FastMathFlags.Differential Revision: https://reviews.llvm.org/D98007
[mlir] turn complex-to-llvm into a partial conversionIt is no longer necessary to also convert other "standard" ops along with thecomplex dialect: the element types are now built-in integers or fl
[mlir] turn complex-to-llvm into a partial conversionIt is no longer necessary to also convert other "standard" ops along with thecomplex dialect: the element types are now built-in integers or floating pointtypes, and the top-level cast between complex and struct is automaticallyinserted and removed in progressive lowering.Reviewed By: herhutDifferential Revision: https://reviews.llvm.org/D95625
[mlir] Add `complex.abs`, `complex.div` and `complex.mul` to ComplexOps.Differential Revision: https://reviews.llvm.org/D94911
[mlir] Add Complex dialect.Differential Revision: https://reviews.llvm.org/D94764