[mlir] Overhaul C/Python registration APIs to properly scope registration/loading activities.Since the very first commits, the Python and C MLIR APIs have had mis-placed registration/load functiona
[mlir] Overhaul C/Python registration APIs to properly scope registration/loading activities.Since the very first commits, the Python and C MLIR APIs have had mis-placed registration/load functionality for dialects, extensions, etc. This was done pragmatically in order to get bootstrapped and then just grew in. Downstreams largely bypass and do their own thing by providing various APIs to register things they need. Meanwhile, the C++ APIs have stabilized around this and it would make sense to follow suit.The thing we have observed in canonical usage by downstreams is that each downstream tends to have native entry points that configure its installation to its preferences with one-stop APIs. This patch leans in to this approach with `RegisterEverything.h` and `mlir._mlir_libs._mlirRegisterEverything` being the one-stop entry points for the "upstream packages". The `_mlir_libs.__init__.py` now allows customization of the environment and Context by adding "initialization modules" to the `_mlir_libs` package. If present, `_mlirRegisterEverything` is treated as such a module. Others can be added by downstreams by adding a `_site_initialize_{i}.py` module, where '{i}' is a number starting with zero. The number will be incremented and corresponding module loaded until one is not found. Initialization modules can:* Perform load time customization to the global environment (i.e. registering passes, hooks, etc).* Define a `register_dialects(registry: DialectRegistry)` function that can extend the `DialectRegistry` that will be used to bootstrap the `Context`.* Define a `context_init_hook(context: Context)` function that will be added to a list of callbacks which will be invoked after dialect registration during `Context` initialization.Note that the `MLIRPythonExtension.RegisterEverything` is not included by default when building a downstream (its corresponding behavior was prior). For downstreams which need the default MLIR initialization to take place, they must add this back in to their Python CMake build just like they add their own components (i.e. to `add_mlir_python_common_capi_library` and `add_mlir_python_modules`). It is perfectly valid to not do this, in which case, only the things explicitly depended on and initialized by downstreams will be built/packaged. If the downstream has not been set up for this, it is recommended to simply add this back for the time being and pay the build time/package size cost.CMake changes:* `MLIRCAPIRegistration` -> `MLIRCAPIRegisterEverything` (renamed to signify what it does and force an evaluation: a number of places were incidentally linking this very expensive target)* `MLIRPythonSoure.Passes` removed (without replacement: just drop)* `MLIRPythonExtension.AllPassesRegistration` removed (without replacement: just drop)* `MLIRPythonExtension.Conversions` removed (without replacement: just drop)* `MLIRPythonExtension.Transforms` removed (without replacement: just drop)Header changes:* `mlir-c/Registration.h` is deleted. Dialect registration functionality is now in `IR.h`. Registration of upstream features are in `mlir-c/RegisterEverything.h`. When updating MLIR and a couple of downstreams, I found that proper usage was commingled so required making a choice vs just blind S&R.Python APIs removed: * mlir.transforms and mlir.conversions (previously only had an __init__.py which indirectly triggered `mlirRegisterTransformsPasses()` and `mlirRegisterConversionPasses()` respectively). Downstream impact: Remove these imports if present (they now happen as part of default initialization). * mlir._mlir_libs._all_passes_registration, mlir._mlir_libs._mlirTransforms, mlir._mlir_libs._mlirConversions. Downstream impact: None expected (these were internally used).C-APIs changed: * mlirRegisterAllDialects(MlirContext) now takes an MlirDialectRegistry instead. It also used to trigger loading of all dialects, which was already marked with a TODO to remove -- it no longer does, and for direct use, dialects must be explicitly loaded. Downstream impact: Direct C-API users must ensure that needed dialects are loaded or call `mlirContextLoadAllAvailableDialects(MlirContext)` to emulate the prior behavior. Also see the `ir.c` test case (e.g. ` mlirContextGetOrLoadDialect(ctx, mlirStringRefCreateFromCString("func"));`). * mlirDialectHandle* APIs were moved from Registration.h (which now is restricted to just global/upstream registration) to IR.h, arguably where it should have been. Downstream impact: include correct header (likely already doing so).C-APIs added: * mlirContextLoadAllAvailableDialects(MlirContext): Corresponds to C++ API with the same purpose.Python APIs added: * mlir.ir.DialectRegistry: Mapping for an MlirDialectRegistry. * mlir.ir.Context.append_dialect_registry(MlirDialectRegistry) * mlir.ir.Context.load_all_available_dialects() * mlir._mlir_libs._mlirAllRegistration: New native extension that exposes a `register_dialects(MlirDialectRegistry)` entry point and performs all upstream pass/conversion/transforms registration on init. In this first step, we eagerly load this as part of the __init__.py and use it to monkey patch the Context to emulate prior behavior. * Type caster and capsule support for MlirDialectRegistryThis should make it possible to build downstream Python dialects that only depend on a subset of MLIR. See: https://github.com/llvm/llvm-project/issues/56037Here is an example PR, minimally adapting IREE to these changes: https://github.com/iree-org/iree/pull/9638/files In this situation, IREE is opting to not link everything, since it is already configuring the Context to its liking. For projects that would just like to not think about it and pull in everything, add `MLIRPythonExtension.RegisterEverything` to the list of Python sources getting built, and the old behavior will continue.Reviewed By: mehdi_amini, ftynseDifferential Revision: https://reviews.llvm.org/D128593
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] Move the Builtin FuncOp to the Func dialectThis commit moves FuncOp out of the builtin dialect, and into the Funcdialect. This move has been planned in some capacity from the momentwe made
[mlir] Move the Builtin FuncOp to the Func dialectThis commit moves FuncOp out of the builtin dialect, and into the Funcdialect. This move has been planned in some capacity from the momentwe made FuncOp an operation (years ago). This commit handles thefunctional aspects of the move, but various aspects are left untouchedto ease migration: func::FuncOp is re-exported into mlir to reducethe actual API churn, the assembly format still accepts the unqualified`func`. These temporary measures will remain for a little while tosimplify migration before being removed.Differential Revision: https://reviews.llvm.org/D121266
[mlir][linalg] Replace linalg.fill by OpDSL variant.The revision removes the linalg.fill operation and renames the OpDSL generated linalg.fill_tensor operation to replace it. After the change, all
[mlir][linalg] Replace linalg.fill by OpDSL variant.The revision removes the linalg.fill operation and renames the OpDSL generated linalg.fill_tensor operation to replace it. After the change, all named structured operations are defined via OpDSL and there are no handwritten operations left.A side-effect of the change is that the pretty printed form changes from:```%1 = linalg.fill(%cst, %0) : f32, tensor<?x?xf32> -> tensor<?x?xf32>```changes to```%1 = linalg.fill ins(%cst : f32) outs(%0 : tensor<?x?xf32>) -> tensor<?x?xf32>```Additionally, the builder signature now takes input and output value ranges as it is the case for all other OpDSL operations:```rewriter.create<linalg::FillOp>(loc, val, output)```changes to```rewriter.create<linalg::FillOp>(loc, ValueRange{val}, ValueRange{output})```All other changes remain minimal. In particular, the canonicalization patterns are the same and the `value()`, `output()`, and `result()` methods are now implemented by the FillOpInterface.Depends On D120726Reviewed By: nicolasvasilacheDifferential Revision: https://reviews.llvm.org/D120728
[mlir][OpDSL] Support pointwise ops with rank zero inputs.Allow pointwise operations to take rank zero input tensors similarly to scalar inputs. Use an empty indexing map to broadcast rank zero ten
[mlir][OpDSL] Support pointwise ops with rank zero inputs.Allow pointwise operations to take rank zero input tensors similarly to scalar inputs. Use an empty indexing map to broadcast rank zero tensors to the iteration domain of the operation.Depends On D120734Reviewed By: nicolasvasilacheDifferential Revision: https://reviews.llvm.org/D120807
[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] 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][OpDSL] Add arithmetic function attributes.The revision extends OpDSL with unary and binary function attributes. A function attribute, makes the operations used in the body of a structured op
[mlir][OpDSL] Add arithmetic function attributes.The revision extends OpDSL with unary and binary function attributes. A function attribute, makes the operations used in the body of a structured operation configurable. For example, a pooling operation may take an aggregation function attribute that specifies if the op shall implement a min or a max pooling. The goal of this revision is to define less and more flexible operations.We may thus for example define an element wise op:```linalg.elem(lhs, rhs, outs=[out], op=BinaryFn.mul)```If the op argument is not set the default operation is used.Depends On D120109Reviewed By: nicolasvasilache, aartbikDifferential Revision: https://reviews.llvm.org/D120110
[mlir][OpDSL] Add type function attributes.Previously, OpDSL operation used hardcoded type conversion operations (cast or cast_unsigned). Supporting signed and unsigned casts thus meant implementin
[mlir][OpDSL] Add type function attributes.Previously, OpDSL operation used hardcoded type conversion operations (cast or cast_unsigned). Supporting signed and unsigned casts thus meant implementing two different operations. Type function attributes allow us to define a single operation that has a cast type function attribute which at operation instantiation time may be set to cast or cast_unsigned. We may for example, defina a matmul operation with a cast argument:```@linalg_structured_opdef matmul(A=TensorDef(T1, S.M, S.K), B=TensorDef(T2, S.K, S.N), C=TensorDef(U, S.M, S.N, output=True), cast=TypeFnAttrDef(default=TypeFn.cast)): C[D.m, D.n] += cast(U, A[D.m, D.k]) * cast(U, B[D.k, D.n])```When instantiating the operation the attribute may be set to the desired cast function:```linalg.matmul(lhs, rhs, outs=[out], cast=TypeFn.cast_unsigned)```The revsion introduces a enum in the Linalg dialect that maps one-by-one to the type functions defined by OpDSL.Reviewed By: aartbikDifferential Revision: https://reviews.llvm.org/D119718
[mlir][OpDSL] Add default value to index attributes.Index attributes had no default value, which means the attribute values had to be set on the operation. This revision adds a default parameter to
[mlir][OpDSL] Add default value to index attributes.Index attributes had no default value, which means the attribute values had to be set on the operation. This revision adds a default parameter to `IndexAttrDef`. After the change, every index attribute has to define a default value. For example, we may define the following strides attribute:``````When using the operation the default stride is used if the strides attribute is not set. The mechanism is implemented using `DefaultValuedAttr`.Additionally, the revision uses the naming index attribute instead of attribute more consistently, which is a preparation for follow up revisions that will introduce function attributes.Depends On D119125Reviewed By: stellaraccidentDifferential Revision: https://reviews.llvm.org/D119126
[mlir][OpDSL] Add support for basic rank polymorphism.Previously, OpDSL did not support rank polymorphism, which required a separate implementation of linalg.fill. This revision extends OpDSL to su
[mlir][OpDSL] Add support for basic rank polymorphism.Previously, OpDSL did not support rank polymorphism, which required a separate implementation of linalg.fill. This revision extends OpDSL to support rank polymorphism for a limited class of operations that access only scalars and tensors of rank zero. At operation instantiation time, it scales these scalar computations to multi-dimensional pointwise computations by replacing the empty indexing maps with identity index maps. The revision does not change the DSL itself, instead it adapts the Python emitter and the YAML generator to generate different indexing maps and and iterators depending on the rank of the first output.Additionally, the revision introduces a `linalg.fill_tensor` operation that in a future revision shall replace the current handwritten `linalg.fill` operation. `linalg.fill_tensor` is thus only temporarily available and will be renamed to `linalg.fill`.Reviewed By: nicolasvasilache, stellaraccidentDifferential Revision: https://reviews.llvm.org/D119003
[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] Fix integration tests broken by D118285[MLIR] Fix integration tests broken by D118285.
[mlir] Move min/max ops from Std to Arith.Differential Revision: https://reviews.llvm.org/D113881
[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] Clean up boolean flags usage in LIT tests* Call `llvm_canonicalize_cmake_booleans` for all CMake options, which are propagated to `lit.local.cfg` files.* Use Python native boolean values
[mlir] Clean up boolean flags usage in LIT tests* Call `llvm_canonicalize_cmake_booleans` for all CMake options, which are propagated to `lit.local.cfg` files.* Use Python native boolean values instead of strings for such options.This fixes the cases, when CMake variables have values other than `ON` (like `TRUE`).This might happen due to IDE integration or due to CMake preset usage.Reviewed By: ftynseDifferential Revision: https://reviews.llvm.org/D110073
[mlir][linalg] Update OpDSL to use the newly introduced min and max ops.Implement min and max using the newly introduced std operations instead of relying on compare and select.Reviewed By: dcaba
[mlir][linalg] Update OpDSL to use the newly introduced min and max ops.Implement min and max using the newly introduced std operations instead of relying on compare and select.Reviewed By: dcaballeDifferential Revision: https://reviews.llvm.org/D111170
[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][linalg] Clear unused linalg tc operationsThese operations are not lowered to from any source dialect and are onlyused for redundant tests. Removing these named ops, along with theirassocia
[mlir][linalg] Clear unused linalg tc operationsThese operations are not lowered to from any source dialect and are onlyused for redundant tests. Removing these named ops, along with theirassociated tests, will make migration to YAML operations much moreconvenient.Reviewed By: stellaraccidentDifferential Revision: https://reviews.llvm.org/D107993
NFC: Add missing import to integration test.
[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][Linalg] Migrate 2D pooling ops from tc definition to yaml definition.This deletes all the pooling ops in LinalgNamedStructuredOpsSpec.tc. All theuses are replaced with the yaml pooling ops.
[mlir][Linalg] Migrate 2D pooling ops from tc definition to yaml definition.This deletes all the pooling ops in LinalgNamedStructuredOpsSpec.tc. All theuses are replaced with the yaml pooling ops.Reviewed By: gysit, rsudermanDifferential Revision: https://reviews.llvm.org/D106181
[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][linalg][python] Add min operation in OpDSL.Add the min operation to OpDSL and introduce a min pooling operation to test the implementation. The patch is a sibling of the max operation patch
[mlir][linalg][python] Add min operation in OpDSL.Add the min operation to OpDSL and introduce a min pooling operation to test the implementation. The patch is a sibling of the max operation patch https://reviews.llvm.org/D105203 and the min operation is again lowered to a compare and select pair.Differential Revision: https://reviews.llvm.org/D105345
[mlir][linalg][python] Introduce python integration test folder.Introduce an integration test folder in the test/python subfolder and move the opsrun.py test into the newly created folder. The test
[mlir][linalg][python] Introduce python integration test folder.Introduce an integration test folder in the test/python subfolder and move the opsrun.py test into the newly created folder. The test verifies named operations end-to-end using both the yaml and the python path.Differential Revision: https://reviews.llvm.org/D105276