[mlir][NFC] Update textual references of `func` to `func.func` in Conversion/ testsThe special case parsing of `func` operations is being removed.
[mlir][NFC] Rename StandardToLLVM to FuncToLLVMThe current StandardToLLVM conversion patterns only really handlethe Func dialect. The pass itself adds patterns for Arithmetic/CFToLLVM, butthose s
[mlir][NFC] Rename StandardToLLVM to FuncToLLVMThe current StandardToLLVM conversion patterns only really handlethe Func dialect. The pass itself adds patterns for Arithmetic/CFToLLVM, butthose should be/will be split out in a followup. This commit focuses solelyon being an NFC rename.Aside from the directory change, the pattern and pass creation API have been renamed: * populateStdToLLVMFuncOpConversionPattern -> populateFuncToLLVMFuncOpConversionPattern * populateStdToLLVMConversionPatterns -> populateFuncToLLVMConversionPatterns * createLowerToLLVMPass -> createConvertFuncToLLVMPassDifferential Revision: https://reviews.llvm.org/D120778
show more ...
[mlir][complex] Lower complex.constant to LLVMThis fixes a regression from 480cd4cb8560532e544fc0c234749912dde759c6Differential Revision: https://reviews.llvm.org/D118347
[mlir:DialectConversion] Restructure how argument/target materializations get invokedThe current implementation invokes materializationswhenever an input operand does not have a mapping for thede
[mlir:DialectConversion] Restructure how argument/target materializations get invokedThe current implementation invokes materializationswhenever an input operand does not have a mapping for thedesired type, i.e. it requires materialization at the earliest possiblepoint. This conflicts with goal of dialect conversion (and also thecurrent documentation) which states that a materialization is onlyrequired if the materialization is supposed to persist after theconversion process has finished.This revision refactors this such that whenever a targetmaterialization "might" be necessary, we insert anunrealized_conversion_cast to act as a temporary materialization.This allows for deferring the invocation of the usermaterialization hooks until the end of the conversion process,where we actually have a better sense if it's actuallynecessary. This has several benefits:* In some cases a target materialization hook is no longer necessaryWhen performing a full conversion, there are some situationswhere a temporary materialization is necessary. Moving forward,these users won't need to provide any target materializations,as the temporary materializations do not require the user toprovide materialization hooks.* getRemappedValue can now handle values that haven't been converted yetBefore this commit, it wasn't well supported to get the remappedvalue of a value that hadn't been converted yet (making itdifficult/impossible to convert multiple operations in manysituations). This commit updates getRemappedValue to properlyhandle this case by inserting temporary materializations whennecessary.Another code-health related benefit is that with this change wecan move a majority of the complexity related to materializationsto the end of the conversion process, instead of handling adhocwhile conversion is happening.Differential Revision: https://reviews.llvm.org/D111620
[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] Factor type reconciliation out of Standard-to-LLVM conversionConversion to the LLVM dialect is being refactored to be more progressive andis now performed as a series of independent passes
[mlir] Factor type reconciliation out of Standard-to-LLVM conversionConversion to the LLVM dialect is being refactored to be more progressive andis now performed as a series of independent passes converting differentdialects. These passes may produce `unrealized_conversion_cast` operations thatrepresent pending conversions between built-in and LLVM dialect types.Historically, a more monolithic Standard-to-LLVM conversion pass did not needthese casts as all operations were converted in one shot. Previous refactoringshave led to the requirement of running the Standard-to-LLVM conversion pass toclean up `unrealized_conversion_cast`s even though the IR had no standardoperations in it. The pass must have been also run the last among all to-LLVMpasses, in contradiction with the partial conversion logic. Additionally, theway it was set up could produce invalid operations by removing casts betweenLLVM and built-in types even when the consumer did not accept the uncastedtype, or could lead to cryptic conversion errors (recursive application of therewrite pattern on `unrealized_conversion_cast` as a means to indicate failureto eliminate casts).In fact, the need to eliminate A->B->A `unrealized_conversion_cast`s is notspecific to to-LLVM conversions and can be factored out into a separate typereconciliation pass, which is achieved in this commit. While the cast operationitself has a folder pattern, it is insufficient in most conversion passes asthe folder only applies to the second cast. Without complex legality setup inthe conversion target, the conversion infra will either consider the castoperations valid and not fold them (a separate canonicalization would benecessary to trigger the folding), or consider the first cast invalid upongeneration and stop with error. The pattern provided by the reconciliation passapplies to the first cast operation instead. Furthermore, having a separatepass makes it clear when `unrealized_conversion_cast`s could not have beeneliminated since it is the only reason why this pass can fail.Reviewed By: nicolasvasilacheDifferential Revision: https://reviews.llvm.org/D109507
[mlir] Set the namespace of the BuiltinDialect to 'builtin'Historically the builtin dialect has had an empty namespace. This has unfortunately created a very awkward situation, where many utilities
[mlir] Set the namespace of the BuiltinDialect to 'builtin'Historically the builtin dialect has had an empty namespace. This has unfortunately created a very awkward situation, where many utilities either have to special case the empty namespace, or just don't work at all right now. This revision adds a namespace to the builtin dialect, and starts to cleanup some of the utilities to no longer handle empty namespaces. For now, the assembly form of builtin operations does not require the `builtin.` prefix. (This should likely be re-evaluated though)Differential Revision: https://reviews.llvm.org/D105149
[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] Fold complex.re(complex.create) and complex.im(complex.create)This extends the folding we already have. A test needs to be adjusted.Differential Revision: https://reviews.llvm.org/D103141
[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