[mlir:FunctionOpInterface] Rename the "type" attribute to "function_type"This removes any potential confusion with the `getType` accessorswhich correspond to SSA results of an operation, and makes
[mlir:FunctionOpInterface] Rename the "type" attribute to "function_type"This removes any potential confusion with the `getType` accessorswhich correspond to SSA results of an operation, and makes itclear what the intent is (i.e. to represent the type of the function).Differential Revision: https://reviews.llvm.org/D121762
show more ...
[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] 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] Document creation of Python bindings for a dialectDocumentation exists about the details of the API but is missing adescription of the overall structure per dialect.Reviewed By: shabalin
[mlir] Document creation of Python bindings for a dialectDocumentation exists about the details of the API but is missing adescription of the overall structure per dialect.Reviewed By: shabalinDifferential Revision: https://reviews.llvm.org/D117002
[mlir] Fix reference to out of date CMake functionReviewed By: ftynseDifferential Revision: https://reviews.llvm.org/D117222
[mlir][docs] Fix obvious spelling mistakes in documentation
[mlir] support interfaces in Python bindingsIntroduce the initial support for operation interfaces in C API and Pythonbindings. Interfaces are a key component of MLIR's extensibility and should be
[mlir] support interfaces in Python bindingsIntroduce the initial support for operation interfaces in C API and Pythonbindings. Interfaces are a key component of MLIR's extensibility and should beavailable in bindings to make use of full potential of MLIR.This initial implementation exposes InferTypeOpInterface all the way to thePython bindings since it can be later used to simplify the operationconstruction methods by inferring their return types instead of requiring theuser to do so. The general infrastructure for binding interfaces is defined andInferTypeOpInterface can be used as an example for binding other interfaces.Reviewed By: gysitDifferential Revision: https://reviews.llvm.org/D111656
[mlir] Fix typos in the Python bindings doc
[mlir][python] Provide some methods and properties for API completenessWhen writing the user-facing documentation, I noticed several inconsistenciesand asymmetries in the Python API we provide. Fi
[mlir][python] Provide some methods and properties for API completenessWhen writing the user-facing documentation, I noticed several inconsistenciesand asymmetries in the Python API we provide. Fix them by adding:- the `owner` property to regions, similarly to blocks;- the `isinstance` method to any class derived from `PyConcreteAttr`, `PyConcreteValue` and `PyConreteAffineExpr`, similar to `PyConcreteType` to enable `isa`-like calls without having to handle exceptions;- a mechanism to create the first block in the region as we could only create blocks relative to other blocks, with is impossible in an empty region.Reviewed By: gysitDifferential Revision: https://reviews.llvm.org/D111556
[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] Limit Python dependency to Development.Module when possible.After CMake 3.18, we are able to limit the scope of the search to justDevelopment.Module. Searching for Development will fail in
[mlir] Limit Python dependency to Development.Module when possible.After CMake 3.18, we are able to limit the scope of the search to justDevelopment.Module. Searching for Development will fail in situationswhere the Python libraries are not available. When possible, limit tojust Development.Module. See:https://pybind11.readthedocs.io/en/stable/compiling.html#findpython-modeReviewed By: stellaraccidentDifferential Revision: https://reviews.llvm.org/D111585
[mlir] add user-level documentation for Python bindingsUntil now, we only had documentation oriented towards developers of thebindings. Provide some documentation for users of the bindings that do
[mlir] add user-level documentation for Python bindingsUntil now, we only had documentation oriented towards developers of thebindings. Provide some documentation for users of the bindings that don't wantor need to understand the inner workings.Reviewed By: nicolasvasilacheDifferential Revision: https://reviews.llvm.org/D111540
Re-engineer MLIR python build support.* Implements all of the discussed features: - Links against common CAPI libraries that are self contained. - Stops using the 'python/' directory at the roo
Re-engineer MLIR python build support.* Implements all of the discussed features: - Links against common CAPI libraries that are self contained. - Stops using the 'python/' directory at the root for everything, opening the namespace up for multiple projects to embed the MLIR python API. - Separates declaration of sources (py and C++) needed to build the extension from building, allowing external projects to build custom assemblies from core parts of the API. - Makes the core python API relocatable (i.e. it could be embedded as something like 'npcomp.ir', 'npcomp.dialects', etc). Still a bit more to do to make it truly isolated but the main structural reset is done. - When building statically, installed python packages are completely self contained, suitable for direct setup and upload to PyPi, et al. - Lets external projects assemble their own CAPI common runtime library that all extensions use. No more possibilities for TypeID issues. - Begins modularizing the API so that external projects that just include a piece pay only for what they use.* I also rolled in a re-organization of the native libraries that matches how I was packaging these out of tree and is a better layering (i.e. all libraries go into a nested _mlir_libs package). There is some further cleanup that I resisted since it would have required source changes that I'd rather do in a followup once everything stabilizes.* Note that I made a somewhat odd choice in choosing to recompile all extensions for each project they are included into (as opposed to compiling once and just linking). While not leveraged yet, this will let us set definitions controlling the namespacing of the extensions so that they can be made to not conflict across projects (with preprocessor definitions).* This will be a relatively substantial breaking change for downstreams. I will handle the npcomp migration and will coordinate with the circt folks before landing. We should stage this and make sure it isn't causing problems before landing.* Fixed a couple of absolute imports that were causing issues.Differential Revision: https://reviews.llvm.org/D106520
[MLIR] Make MLIR cmake variable names consistentFix inconsistent MLIR CMake variable names. Consistently name them asMLIR_ENABLE_<feature>.Eg: MLIR_CUDA_RUNNER_ENABLED -> MLIR_ENABLE_CUDA_RUNNER
[MLIR] Make MLIR cmake variable names consistentFix inconsistent MLIR CMake variable names. Consistently name them asMLIR_ENABLE_<feature>.Eg: MLIR_CUDA_RUNNER_ENABLED -> MLIR_ENABLE_CUDA_RUNNERMLIR follows (or has mostly followed) the convention of namingcmake enabling variables in the from MLIR_ENABLE_... etc. Using aconvention here is easy and also important for convenience. A counterpattern was started with variables named MLIR_..._ENABLED. This led to asequence of related counter patterns: MLIR_CUDA_RUNNER_ENABLED,MLIR_ROCM_RUNNER_ENABLED, etc.. From a naming standpoint, the imperativeform is more meaningful. Additional discussion at:https://llvm.discourse.group/t/mlir-cmake-enable-variable-naming-convention/3520Switch all inconsistent ones to the ENABLE form. Keep the couple of oldmappings needed until buildbot config is migrated.Differential Revision: https://reviews.llvm.org/D102976
Move MLIR python sources to mlir/python.* NFC but has some fixes for CMake glitches discovered along the way (things not cleaning properly, co-mingled depends).* Includes previously unsubmitted fi
Move MLIR python sources to mlir/python.* NFC but has some fixes for CMake glitches discovered along the way (things not cleaning properly, co-mingled depends).* Includes previously unsubmitted fix in D98681 and a TODO to fix it more appropriately in a smaller followup.Differential Revision: https://reviews.llvm.org/D101493
NFC: Update MLIR python bindings docs to install deps via requirements.txt.* Also adds some verbiage about upgrading `pip` itself, since this is a common source of issues.Differential Revision:
NFC: Update MLIR python bindings docs to install deps via requirements.txt.* Also adds some verbiage about upgrading `pip` itself, since this is a common source of issues.Differential Revision: https://reviews.llvm.org/D99522
[mlir][python] Add docs for op class extension mechanism.Differential Revision: https://reviews.llvm.org/D99387
[mlir][python] Reorganize MLIR python into namespace packages.* Only leaf packages are non-namespace packages. This allows most of the top levels to be split into different directories or deploymen
[mlir][python] Reorganize MLIR python into namespace packages.* Only leaf packages are non-namespace packages. This allows most of the top levels to be split into different directories or deployment packages. In the previous state, the presence of __init__.py files at each level meant that the entire tree could only ever exist in one physical directory on the path.* This changes the API usage slightly: `import mlir` will no longer do a deep import of `mlir.ir`, etc. This may necessitate some client code changes.* Dialect gen code was restructured so that the user is responsible for providing the `my_dialect.py` file, which then must import its peer `_my_dialect_ops_gen`. This gives complete control of the dialect namespace to the user instead of to tablegen code, allowing further dialect-specific python APIs.* Correspondingly, the previous extension modules `_my_dialect.py` are now `_my_dialect_ops_ext.py`.* Now that the `linalg` namespace is open, moved the `linalg_opdsl` tool into it.* This may require some corresponding downstream adjustments to npcomp, circt, et al: * Probably some shallow imports need to be converted to deep imports (i.e. not `import mlir` brings in the world). * Each tablegen generated dialect now needs an explicit `foo.py` which does a `from ._foo_ops_gen import *`. This is similar to the way that generated code operates in the C++ world. * If providing dialect op extensions, those need to be moved from `_foo.py` -> `_foo_ops_ext.py`.Differential Revision: https://reviews.llvm.org/D98096
[mlir][Python] Roll up of python API fixes.* As discussed, fixes the ordering or (operands, results) -> (results, operands) in various `create` like methods.* Fixes a syntax error in an ODS access
[mlir][Python] Roll up of python API fixes.* As discussed, fixes the ordering or (operands, results) -> (results, operands) in various `create` like methods.* Fixes a syntax error in an ODS accessor method.* Removes the linalg example in favor of a test case that exercises the same.* Fixes FuncOp visibility to properly use None instead of the empty string and defaults it to None.* Implements what was documented for requiring that trailing __init__ args `loc` and `ip` are keyword only.* Adds a check to `InsertionPoint.insert` so that if attempting to insert past the terminator, an exception is raised telling you what to do instead. Previously, this would crash downstream (i.e. when trying to print the resultant module).* Renames `_ods_build_default` -> `build_generic` and documents it.* Removes `result` from the list of prohibited words and for single-result ops, defaults to naming the result `result`, thereby matching expectations and what is already implemented on the base class.* This was intended to be a relatively small set of changes to be inlined with the broader support for ODS generating the most specific builder, but it spidered out once actually testing various combinations, so rolling up separately.Differential Revision: https://reviews.llvm.org/D95320
[mlir][python] Factor out standalone OpView._ods_build_default class method.* This allows us to hoist trait level information for regions and sized-variadic to class level attributes (_ODS_REGIONS,
[mlir][python] Factor out standalone OpView._ods_build_default class method.* This allows us to hoist trait level information for regions and sized-variadic to class level attributes (_ODS_REGIONS, _ODS_OPERAND_SEGMENTS, _ODS_RESULT_SEGMENTS).* Eliminates some splicey python generated code in favor of a native helper for it.* Makes it possible to implement custom, variadic and region based builders with one line of python, without needing to manually code access to the segment attributes.* Needs follow-on work for region based callbacks and support for SingleBlockImplicitTerminator.* A follow-up will actually add ODS support for generating custom Python builders that delegate to this new method.* Also includes the start of an e2e sample for constructing linalg ops where this limitation was discovered (working progressively through this example and cleaning up as I go).Differential Revision: https://reviews.llvm.org/D94738
NFC: Document current MLIR Python ODS conventions.* We had let the documentation get stale and catching it up prior to proposing changes.
[NFC] Update some mlir python documentation.* Development setup recommendations.* Test updates to match what we actually do.* Update cmake variable `PYTHON_EXECUTABLE` -> `Python3_EXECUTABLE` to
[NFC] Update some mlir python documentation.* Development setup recommendations.* Test updates to match what we actually do.* Update cmake variable `PYTHON_EXECUTABLE` -> `Python3_EXECUTABLE` to match the upgrade to python3 repo wide.
[mlir][Python] Support finding pybind11 from the python environment.* Makes `pip install pybind11` do the right thing with no further config.* Since we now require a version of pybind11 greater th
[mlir][Python] Support finding pybind11 from the python environment.* Makes `pip install pybind11` do the right thing with no further config.* Since we now require a version of pybind11 greater than many LTS OS installs (>=2.6), a more convenient way to get a recent version is preferable.* Also adds the version spec to find_package so it will skip older versions that may be lying around.* Tested the full matrix of old system install, no system install, pip install and no pip install.Differential Revision: https://reviews.llvm.org/D91903
[mlir] Get array from the dense elements attribute with buffer protocol.- Add `mlirElementsAttrGetType` C API.- Add `def_buffer` binding to PyDenseElementsAttribute.- Implement the protocol to ac
[mlir] Get array from the dense elements attribute with buffer protocol.- Add `mlirElementsAttrGetType` C API.- Add `def_buffer` binding to PyDenseElementsAttribute.- Implement the protocol to access the buffer.Differential Revision: https://reviews.llvm.org/D91021
NFC: Wrap lines in Python.md.
12