| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir][python] Add python support for async dialect and passes. since the async keyword is reserved in python, the dialect is called async_dialect. Differential Revision: https://reviews.llvm.org/D101447 | 5 年前 | |
[mlir] Split out Python bindings for dialects into separate libs Historically, the bindings for the Linalg dialect were included into the "core" bindings library because they depended on the C++ implementation of the "core" bindings. The other dialects followed the pattern. Now that this dependency is gone, split out each dialect into a separate Python extension library. Depends On D116649, D116605 Reviewed By: stellaraccident Differential Revision: https://reviews.llvm.org/D116662 | 4 年前 | |
[mlir] Introduce Python bindings for the PDL dialect This change adds full python bindings for PDL, including types and operations with additional mixins to make operation construction more similar to the PDL syntax. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D117458 | 4 年前 | |
Ensure newlines at the end of files (NFC) | 4 年前 | |
[mlir][sparse] introduce new 2:4 block sparsity level type. Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D155128 | 2 年前 | |
[MLIR][python bindings] Add TypeCaster for returning refined types from python APIs depends on D150839 This diff uses MlirTypeID to register TypeCasters (i.e., [](PyType pyType) -> DerivedTy { return pyType; }) for all concrete types (i.e., PyConcrete<...>) that are then queried for (by MlirTypeID) and called in struct type_caster<MlirType>::cast. The result is that anywhere an MlirType mlirType is returned from a python binding, that mlirType is automatically cast to the correct concrete type. For example: c0 = arith.ConstantOp(f32, 0.0) # CHECK: F32Type(f32) print(repr(c0.result.type)) unranked_tensor_type = UnrankedTensorType.get(f32) unranked_tensor = tensor.FromElementsOp(unranked_tensor_type, [c0]).result # CHECK: UnrankedTensorType print(type(unranked_tensor.type).__name__) # CHECK: UnrankedTensorType(tensor<*xf32>) print(repr(unranked_tensor.type)) This functionality immediately extends to typed attributes (i.e., attr.type). The diff also implements similar functionality for mlir_type_subclasses but in a slightly different way - for such types (which have no cpp corresponding class or struct) the user must provide a type caster in python (similar to how AttrBuilder works) or in cpp as a py::cpp_function. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D150927 | 3 年前 | |
[mlir] Fix and test python bindings for dump_to_object_file Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D136334 | 3 年前 | |
[mlir][python] Add basic python support for GPU dialect and passes Differential Revision: https://reviews.llvm.org/D101449 | 5 年前 | |
[MLIR][python bindings] Add TypeCaster for returning refined types from python APIs depends on D150839 This diff uses MlirTypeID to register TypeCasters (i.e., [](PyType pyType) -> DerivedTy { return pyType; }) for all concrete types (i.e., PyConcrete<...>) that are then queried for (by MlirTypeID) and called in struct type_caster<MlirType>::cast. The result is that anywhere an MlirType mlirType is returned from a python binding, that mlirType is automatically cast to the correct concrete type. For example: c0 = arith.ConstantOp(f32, 0.0) # CHECK: F32Type(f32) print(repr(c0.result.type)) unranked_tensor_type = UnrankedTensorType.get(f32) unranked_tensor = tensor.FromElementsOp(unranked_tensor_type, [c0]).result # CHECK: UnrankedTensorType print(type(unranked_tensor.type).__name__) # CHECK: UnrankedTensorType(tensor<*xf32>) print(repr(unranked_tensor.type)) This functionality immediately extends to typed attributes (i.e., attr.type). The diff also implements similar functionality for mlir_type_subclasses but in a slightly different way - for such types (which have no cpp corresponding class or struct) the user must provide a type caster in python (similar to how AttrBuilder works) or in cpp as a py::cpp_function. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D150927 | 3 年前 | |
[MLIR][python bindings] use pybind C++ APIs for throwing python errors. Differential Revision: https://reviews.llvm.org/D151167 | 3 年前 | |
[backport][mlir] Add Python bindings for DenseResourceElementsAttr. (#66319) Only construction and type casting are implemented. The method to create is explicitly named "unsafe" and the documentation calls out what the caller is responsible for. There really isn't a better way to do this and retain the power-user feature this represents. originally by: Stella Laurenzo reference: https://github.com/llvm/llvm-project/commit/f66cd9e9556a53142a26a5c21a72e21f1579 | 9 个月前 | |
Finish renaming getOperandSegmentSizeAttr() from operand_segment_sizes to operandSegmentSizes This renaming started with the native ODS support for properties, this is completing it. A mass automated textual rename seems safe for most codebases. Drop also the ods prefix to keep the accessors the same as they were before this change: properties.odsOperandSegmentSizes reverts back to: properties.operandSegementSizes The ODS prefix was creating divergence between all the places and make it harder to be consistent. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D157173 | 2 年前 | |
[MLIR][python bindings] Fix inferReturnTypes + AttrSizedOperandSegments for optional operands Right now inferTypeOpInterface.inferReturnTypes fails because there's a cast in there to py::sequence which throws a TypeError when it tries to cast the Nones. Note Nones are inserted into operands for omitted operands passed to the generated builder: operands.append(_get_op_result_or_value(start) if start is not None else None) operands.append(_get_op_result_or_value(stop) if stop is not None else None) operands.append(_get_op_result_or_value(step) if step is not None else None) Note also that skipping appending to the list operands doesn't work either because [[ https://github.com/llvm/llvm-project/blob/27c37327da67020f938aabf0f6405f57d688441e/mlir/lib/Bindings/Python/IRCore.cpp#L1585 | build generic ]] checks against the number of operand segments expected. Currently the only way around is to handroll through ir.Operation.create. Reviewed By: rkayaith Differential Revision: https://reviews.llvm.org/D151409 | 3 年前 | |
[MLIR][python bindings] Add TypeCaster for returning refined types from python APIs depends on D150839 This diff uses MlirTypeID to register TypeCasters (i.e., [](PyType pyType) -> DerivedTy { return pyType; }) for all concrete types (i.e., PyConcrete<...>) that are then queried for (by MlirTypeID) and called in struct type_caster<MlirType>::cast. The result is that anywhere an MlirType mlirType is returned from a python binding, that mlirType is automatically cast to the correct concrete type. For example: c0 = arith.ConstantOp(f32, 0.0) # CHECK: F32Type(f32) print(repr(c0.result.type)) unranked_tensor_type = UnrankedTensorType.get(f32) unranked_tensor = tensor.FromElementsOp(unranked_tensor_type, [c0]).result # CHECK: UnrankedTensorType print(type(unranked_tensor.type).__name__) # CHECK: UnrankedTensorType(tensor<*xf32>) print(repr(unranked_tensor.type)) This functionality immediately extends to typed attributes (i.e., attr.type). The diff also implements similar functionality for mlir_type_subclasses but in a slightly different way - for such types (which have no cpp corresponding class or struct) the user must provide a type caster in python (similar to how AttrBuilder works) or in cpp as a py::cpp_function. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D150927 | 3 年前 | |
[mlir][py] Reuse more of CAPI build time inference. This reduces code generated for type inference and instead reuses facilities CAPI side that performed same role. Differential Revision: https://reviews.llvm.org/D156041t | 2 年前 | |
[mlir][python] Downcast attributes in more places Update remaining PyAttribute-returning APIs to return MlirAttribute instead, so that they go through the downcasting mechanism. Reviewed By: makslevental Differential Revision: https://reviews.llvm.org/D154462 | 2 年前 | |
[mlir] Register Linalg passes in C API and Python Bindings Provide a registration mechanism for Linalg dialect-specific passes in C API and Python bindings. These are being built into the dialect library but exposed in separate headers (C) or modules (Python). Differential Revision: https://reviews.llvm.org/D99431 | 5 年前 | |
[MLIR][python bindings] Add TypeCaster for returning refined types from python APIs depends on D150839 This diff uses MlirTypeID to register TypeCasters (i.e., [](PyType pyType) -> DerivedTy { return pyType; }) for all concrete types (i.e., PyConcrete<...>) that are then queried for (by MlirTypeID) and called in struct type_caster<MlirType>::cast. The result is that anywhere an MlirType mlirType is returned from a python binding, that mlirType is automatically cast to the correct concrete type. For example: c0 = arith.ConstantOp(f32, 0.0) # CHECK: F32Type(f32) print(repr(c0.result.type)) unranked_tensor_type = UnrankedTensorType.get(f32) unranked_tensor = tensor.FromElementsOp(unranked_tensor_type, [c0]).result # CHECK: UnrankedTensorType print(type(unranked_tensor.type).__name__) # CHECK: UnrankedTensorType(tensor<*xf32>) print(repr(unranked_tensor.type)) This functionality immediately extends to typed attributes (i.e., attr.type). The diff also implements similar functionality for mlir_type_subclasses but in a slightly different way - for such types (which have no cpp corresponding class or struct) the user must provide a type caster in python (similar to how AttrBuilder works) or in cpp as a py::cpp_function. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D150927 | 3 年前 | |
[MLIR][python bindings] use pybind C++ APIs for throwing python errors. Differential Revision: https://reviews.llvm.org/D151167 | 3 年前 | |
Ensure newlines at the end of files (NFC) | 4 年前 | |
[MLIR][CAPI] Move DenseMapInfo<MlirTypeID> I mistakenly put this in mlir/CAPI/Support.h at some point during the flurry of refactoring of TypeCasters but as @jpienaar rightly pointed out, it doesn't belong there. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D151669 | 3 年前 | |
[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 MlirDialectRegistry This 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/56037 Here 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, ftynse Differential Revision: https://reviews.llvm.org/D128593 | 3 年前 | |
[mlir][sparse][capi][python] add sparse tensor passes First set of "boilerplate" to get sparse tensor passes available through CAPI and Python. Reviewed By: stellaraccident Differential Revision: https://reviews.llvm.org/D102362 | 5 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 9 个月前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 5 年前 |