Revert "[MLIR] Generic 'malloc', 'aligned_alloc' and 'free' functions"This reverts commit 3e21fb616d9a1b29bf9d1a1ba484add633d6d5b3.A lot of integration tests are failing on the bot.
[MLIR] Generic 'malloc', 'aligned_alloc' and 'free' functionsWhen converted to the LLVM dialect, the memref.alloc and memref.free operations were generating calls to hardcoded 'malloc' and 'free' f
[MLIR] Generic 'malloc', 'aligned_alloc' and 'free' functionsWhen converted to the LLVM dialect, the memref.alloc and memref.free operations were generating calls to hardcoded 'malloc' and 'free' functions. This didn't leave any freedom to users to provide their custom implementation. Those operations now convert into calls to '_mlir_alloc' and '_mlir_free' functions, which have also been implemented into the runtime support library as wrappers to 'malloc' and 'free'. The same has been done for the 'aligned_alloc' function.Reviewed By: ftynseDifferential Revision: https://reviews.llvm.org/D128791
show more ...
[mlir][NFC] Update textual references of `func` to `func.func` in examples+python scriptsThe special case parsing of `func` operations is being removed.
[mlir] Prefix pass manager options with `mlir-`With this change, there's going to be a clear distinction between LLVMand MLIR pass maanger options (e.g. `-mlir-print-after-all` vs`-print-after-al
[mlir] Prefix pass manager options with `mlir-`With this change, there's going to be a clear distinction between LLVMand MLIR pass maanger options (e.g. `-mlir-print-after-all` vs`-print-after-all`). This change is desirable from the point of view ofprojects that depend on both LLVM and MLIR, e.g. Flang.For consistency, all pass manager options in MLIR are prefixed with`mlir-`, even options that don't have equivalents in LLVM .Differential Revision: https://reviews.llvm.org/D123495
[mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`I am not sure about the meaning of Type in the name (was it meant be interpreted as Kind?), and given the importance and
[mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`I am not sure about the meaning of Type in the name (was it meant be interpreted as Kind?), and given the importance and meaning of Type in the context of MLIR, its probably better to rename it. Given the comment in the source code, the suggestion in the GitHub issue and the final discussions in the review, this patch renames the OperandType to UnresolvedOperand.Fixes https://github.com/llvm/llvm-project/issues/54446Differential Revision: https://reviews.llvm.org/D122142
[mlir][toy] Define a FuncOp operation in toy and drop the dependence on FuncOpFuncOp is being moved out of the builtin dialect, and defining a customtoy operation showcases various aspects of defi
[mlir][toy] Define a FuncOp operation in toy and drop the dependence on FuncOpFuncOp is being moved out of the builtin dialect, and defining a customtoy operation showcases various aspects of defining function-like operation(e.g. inlining, passes, etc.).Differential Revision: https://reviews.llvm.org/D121264
[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
[mlir][NFC] Remove several dead references to the old standard 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] Update Toy operations to use the `hasCustomAssemblyFormat` fieldThe parser/printer fields are deprecated and in the process of being removed.
[mlir] Split out a new ControlFlow dialect from StandardThis dialect is intended to model lower level/branch based control-flow constructs. The initial setof operations are: AssertOp, BranchOp, Co
[mlir] Split out a new ControlFlow dialect from StandardThis dialect is intended to model lower level/branch based control-flow constructs. The initial setof operations are: AssertOp, BranchOp, CondBranchOp, SwitchOp; all split out from the currentstandard dialect.See https://discourse.llvm.org/t/standard-dialect-the-final-chapter/6061Differential Revision: https://reviews.llvm.org/D118966
[mlir][NFC] Update Toy operations to use `hasVerifier` instead of `verifier`The verifier field is deprecated, and slated for removal.Differential Revision: https://reviews.llvm.org/D118816
Remove OpTrait, AttrTrait and TypeTrait - Remove the `{Op,Attr,Type}Trait` TableGen classes and replace with `Trait` - Rename `OpTraitList` to `TraitList` and use it in a few placesThe bulk of
Remove OpTrait, AttrTrait and TypeTrait - Remove the `{Op,Attr,Type}Trait` TableGen classes and replace with `Trait` - Rename `OpTraitList` to `TraitList` and use it in a few placesThe bulk of this change is a mechanical s/OpTrait/Trait/ throughout the codebase.Reviewed By: rriddle, jpienaar, herhutDifferential Revision: https://reviews.llvm.org/D118543
[mlir][NFC] Add a using for llvm::SMLoc/llvm::SMRange to LLVM.hThese are used pervasively during parsing.Differential Revision: https://reviews.llvm.org/D118291
[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
[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][docs] Fix name of get arith->LLVM patterns in docs
[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][docs] A friendlier improvement for the Toy tutorial chapter 4.Add notes for discarding private-visible functions in the Toy tutorial chapter 4.Reviewed By: mehdi_aminiDifferential Revisi
[mlir][docs] A friendlier improvement for the Toy tutorial chapter 4.Add notes for discarding private-visible functions in the Toy tutorial chapter 4.Reviewed By: mehdi_aminiDifferential Revision: https://reviews.llvm.org/D108026
[MLIR] Fix documentation of the `ExecutionEngine` in the toy tutorial exampleDifferential Revision: https://reviews.llvm.org/D105813
Fix typo in Toy Tutorial Ch-4multiple_transpose -> multiply_transpose
Fix typo in Toy tutorial Ch1This aligns the website with the actual test case in the repo.Reviewed By: mehdi_aminiDifferential Revision: https://reviews.llvm.org/D84193
[mlir][doc] Fix links and references in documentation of TutorialsThis patch is the third in a series of patches fixing markdown links and references inside the mlir documentation.This patch addr
[mlir][doc] Fix links and references in documentation of TutorialsThis patch is the third in a series of patches fixing markdown links and references inside the mlir documentation.This patch addresses all broken references to other markdown files and sections inside the Tutorials folder.Differential Revision: https://reviews.llvm.org/D103017
[mlir][docs] Fix links to index and integer typesReviewed By: mehdi_aminiDifferential Revision: https://reviews.llvm.org/D102922
Define a `NoTerminator` traits that allows operations with a single block region to not provide a terminatorIn particular for Graph Regions, the terminator needs is just ahistorical artifact of th
Define a `NoTerminator` traits that allows operations with a single block region to not provide a terminatorIn particular for Graph Regions, the terminator needs is just ahistorical artifact of the generalization of MLIR from CFG region.Operations like Module don't need a terminator, and before Modulemigrated to be an operation with region there wasn't any needed.To validate the feature, the ModuleOp is migrated to use this trait andthe ModuleTerminator operation is deleted.This patch is likely to break clients, if you're in this case:- you may iterate on a ModuleOp with `getBody()->without_terminator()`, the solution is simple: just remove the ->without_terminator!- you created a builder with `Builder::atBlockTerminator(module_body)`, just use `Builder::atBlockEnd(module_body)` instead.- you were handling ModuleTerminator: it isn't needed anymore.- for generic code, a `Block::mayNotHaveTerminator()` may be used.Differential Revision: https://reviews.llvm.org/D98468
1234