| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
X=MemoryEffects (#176920)
Provides the infrastructure for implementing and late-binding
OpInterfaces from Python.
* On the mlir-c API declaration side, each `XOpInterface` has a callback
struct, with a callback for each method and a userdata member (provided
as an arg to each method), and a
`mlirXOpInterfaceAttachFallbackModel(ctx, op_name, callbacks)` func.
* This CAPI is implemented by defining a subclass of
`XOpInterface::FallbackModel` that holds the callback struct and has
each method call the corresponding callback (with userdata as an arg).
Given a callback struct, a new `FallbackModel` is created and attached,
i.e. late bound, to the named op. (MLIR's interface infrastructure is
such that the thus registered `FallbackModel` will be returned in case
the op gets cast to the `XOpInterface`.)
* On the Python side, we expose a stand-in `XOpInterface` base class
which has one (class)method: `XOpInterface.attach(cls, op_name, ctx)`.
Python users subclass this class (`class MyInterfaceImpl(XOpInterface):
...`) and implement the interface's methods (with the right names and
signatures). The user calls `attach` on the subclass
(`MyInterfaceImpl.attach("my_dialect.my_op", ctx)`) which prepares the
callbacks struct _with userdata set to the subclass_ (as we use it to
lookup methods). These callbacks (and userdata) are then registered as
an `XOpInterface::FallbackModel` by
`mlirXOpInterfaceAttachFallbackModel(...)`. From then on the Python
methods will be used to respond to calls to the interface methods
(originating in C++).
This PR enables implementing the TransformOpInterface and the
MemoryEffectsOpInterface, both of which are required for making an op
into a transform op.
Everything besides the above linked code is there to facilitate exposing
the interfaces: the right types for the arguments of the methods are
exposed as are functions/methods for manipulating these arguments (e.g.
specifying side effects on `OpOperand`s and `OpResult`s and being able
to access and set the transform handles associated with args and
results).
|
|
This PR extends the `DIDerivedType` with the `flags` field.
Fixes https://github.com/llvm/llvm-project/issues/177725
|
|
|
|
|
|
We are trying to make a wrapper of MLIR for Julia in
https://github.com/JuliaLabs/MLIR.jl, but some dialects are missing in
`libMLIR-C`. This PR adds them.
|
|
This PR is quite similiar to #174700.
In this PR, I added a C API for each (upstream) MLIR attributes to
retrieve its name (for example, `StringAttr -> mlirStringAttrGetName()
-> "builtin.string"`), and exposed a corresponding type_name class
attribute in the Python bindings (e.g., `StringAttr.attr_name ->
"builtin.string"`). This can be used in various places to avoid
hard-coded strings, such as eliminating the manual string in
`irdl.base("#builtin.string")`.
Note that parts of this PR (mainly mechanical changes) were produced via
GitHub Copilot and GPT-5.2. I have manually reviewed the changes and
verified them with tests to ensure correctness.
|
|
In this PR, I added a C API for each (upstream) MLIR type to retrieve
its type name (for example, `IntegerType` -> `mlirIntegerTypeGetName()`
-> `"builtin.integer"`), and exposed a corresponding `type_name` class
attribute in the Python bindings (e.g., `IntegerType.type_name` ->
`"builtin.integer"`). This can be used in various places to avoid
hard-coded strings, such as eliminating the manual string in
`irdl.base("!builtin.integer")`.
Note that parts of this PR (mainly mechanical changes) were produced via
GitHub Copilot and GPT-5.2. I have manually reviewed the changes and
verified them with tests to ensure correctness.
|
|
`Type.isinstance` (#172892)
We've been able to do `isinstance(x, Type)` for a quite a while now
(since
https://github.com/llvm/llvm-project/commit/bfb1ba752655bf09b35c486f6cc9817dbedfb1bb)
so remove `Type.isinstance` and the the special-casing
(`_is_integer_type`, `_is_floating_point_type`, `_is_index_type`) in
some places (and therefore support various `fp8`, `fp6`, `fp4` types).
|
|
My bad, I thought that the build was being run for PRs, everything
succeeded and didn't test out on local.
Now main branch is throwing these errors on CI:
```
[490/2482] Building CXX object tools/mlir/lib/CAPI/Dialect/CMakeFiles/obj.MLIRCAPIComplex.dir/Complex.cpp.o
FAILED: tools/mlir/lib/CAPI/Dialect/CMakeFiles/obj.MLIRCAPIComplex.dir/Complex.cpp.o
/usr/local/bin/c++ -DGTEST_HAS_RTTI=0 -DMLIR_CAPI_BUILDING_LIBRARY=1 -D_DEBUG -D_GLIBCXX_ASSERTIONS -D_GLIBCXX_USE_CXX11_ABI=1 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/home/tcwg-buildbot/worker/clang-aarch64-sve2-vla/stage1/tools/mlir/lib/CAPI/Dialect -I/home/tcwg-buildbot/worker/clang-aarch64-sve2-vla/llvm/mlir/lib/CAPI/Dialect -I/home/tcwg-buildbot/worker/clang-aarch64-sve2-vla/stage1/tools/mlir/include -I/home/tcwg-buildbot/worker/clang-aarch64-sve2-vla/llvm/mlir/include -I/home/tcwg-buildbot/worker/clang-aarch64-sve2-vla/stage1/include -I/home/tcwg-buildbot/worker/clang-aarch64-sve2-vla/llvm/llvm/include -mcpu=neoverse-v2 -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wno-pass-failed -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -Wundef -Werror=mismatched-tags -O3 -DNDEBUG -std=c++17 -fvisibility=hidden -fno-exceptions -funwind-tables -fno-rtti -UNDEBUG -MD -MT tools/mlir/lib/CAPI/Dialect/CMakeFiles/obj.MLIRCAPIComplex.dir/Complex.cpp.o -MF tools/mlir/lib/CAPI/Dialect/CMakeFiles/obj.MLIRCAPIComplex.dir/Complex.cpp.o.d -o tools/mlir/lib/CAPI/Dialect/CMakeFiles/obj.MLIRCAPIComplex.dir/Complex.cpp.o -c /home/tcwg-buildbot/worker/clang-aarch64-sve2-vla/llvm/mlir/lib/CAPI/Dialect/Complex.cpp
../llvm/mlir/lib/CAPI/Dialect/Complex.cpp:15:45: error: no member named 'complex' in namespace 'mlir'
15 | mlir::complex::ComplexDialect)
| ~~~~~~^
../llvm/mlir/include/mlir/CAPI/Registration.h:39:30: note: expanded from macro 'MLIR_DEFINE_CAPI_DIALECT_REGISTRATION'
39 | unwrap(registry)->insert<ClassName>(); \
| ^~~~~~~~~
../llvm/mlir/lib/CAPI/Dialect/Complex.cpp:15:45: error: no member named 'complex' in namespace 'mlir'
15 | mlir::complex::ComplexDialect)
| ~~~~~~^
../llvm/mlir/include/mlir/CAPI/Registration.h:42:51: note: expanded from macro 'MLIR_DEFINE_CAPI_DIALECT_REGISTRATION'
42 | return wrap(unwrap(context)->getOrLoadDialect<ClassName>()); \
| ^~~~~~~~~
../llvm/mlir/lib/CAPI/Dialect/Complex.cpp:15:45: error: no member named 'complex' in namespace 'mlir'
15 | mlir::complex::ComplexDialect)
| ~~~~~~^
../llvm/mlir/include/mlir/CAPI/Registration.h:45:17: note: expanded from macro 'MLIR_DEFINE_CAPI_DIALECT_REGISTRATION'
45 | return wrap(ClassName::getDialectNamespace()); \
| ^~~~~~~~~
../llvm/mlir/lib/CAPI/Dialect/Complex.cpp:18:14: error: use of undeclared identifier 'ComplexAttr'
18 | return isa<ComplexAttr>(unwrap(attr));
| ^~~~~~~~~~~
../llvm/mlir/lib/CAPI/Dialect/Complex.cpp:24:7: error: use of undeclared identifier 'complex'
24 | complex::NumberAttr::get(cast<ComplexType>(unwrap(type)), real, imag));
| ^
../llvm/mlir/lib/CAPI/Dialect/Complex.cpp:24:37: error: unknown type name 'ComplexType'; did you mean 'mlir::ComplexType'?
24 | complex::NumberAttr::get(cast<ComplexType>(unwrap(type)), real, imag));
| ^~~~~~~~~~~
| mlir::ComplexType
tools/mlir/include/mlir/IR/BuiltinTypes.h.inc:733:7: note: 'mlir::ComplexType' declared here
733 | class ComplexType : public ::mlir::Type::TypeBase<ComplexType, ::mlir::Type, detail::ComplexTypeStorage> {
| ^
../llvm/mlir/lib/CAPI/Dialect/Complex.cpp:24:32: warning: use of function template name with no prior declaration in function call with explicit template arguments is a C++20 extension [-Wc++20-extensions]
24 | complex::NumberAttr::get(cast<ComplexType>(unwrap(type)), real, imag));
| ^
../llvm/mlir/lib/CAPI/Dialect/Complex.cpp:29:15: error: use of undeclared identifier 'complex'
29 | return wrap(complex::NumberAttr::getChecked(
| ^
../llvm/mlir/lib/CAPI/Dialect/Complex.cpp:30:25: error: unknown type name 'ComplexType'; did you mean 'mlir::ComplexType'?
30 | unwrap(loc), cast<ComplexType>(unwrap(type)), real, imag));
| ^~~~~~~~~~~
| mlir::ComplexType
tools/mlir/include/mlir/IR/BuiltinTypes.h.inc:733:7: note: 'mlir::ComplexType' declared here
733 | class ComplexType : public ::mlir::Type::TypeBase<ComplexType, ::mlir::Type, detail::ComplexTypeStorage> {
| ^
../llvm/mlir/lib/CAPI/Dialect/Complex.cpp:30:20: warning: use of function template name with no prior declaration in function call with explicit template arguments is a C++20 extension [-Wc++20-extensions]
30 | unwrap(loc), cast<ComplexType>(unwrap(type)), real, imag));
| ^
../llvm/mlir/lib/CAPI/Dialect/Complex.cpp:34:15: error: use of undeclared identifier 'complex'
34 | return cast<complex::NumberAttr>(unwrap(attr)).getRealAsDouble();
| ^
../llvm/mlir/lib/CAPI/Dialect/Complex.cpp:38:15: error: use of undeclared identifier 'complex'
38 | return cast<complex::NumberAttr>(unwrap(attr)).getImagAsDouble();
| ^
../llvm/mlir/lib/CAPI/Dialect/Complex.cpp:42:15: error: use of undeclared identifier 'complex'
42 | return wrap(complex::NumberAttr::getTypeID());
| ^
```
This PR fixes these errors.
Tested on local that `MLIRCAPIComplex` target (the one erroring) now
compiles correctly on local.
|
|
The `complex` dialect is missing from the MLIR's C-API. This PR adds the
functions for registration of the dialect and handling of
`complex::NumberAttr`.
---------
Co-authored-by: Oleksandr "Alex" Zinenko <azinenko@amd.com>
|
|
Add bindings for:
- `TDMBaseType`
- `TDMDescriptorType`
- `TDMGatherBaseType`
|
|
This add the basic APIs to create VariadicityAttr and
VariadicityArrayAttr attributes from the C API. This is necessary for
C API users that want to create IRDL dialect declarations.
|
|
downcasting (#169383)
|
|
These were added in https://github.com/llvm/llvm-project/pull/165803.
|
|
Dimensions from Affine Maps (#167587)
This PR exposes `linalg::inferContractionDims(ArrayRef<AffineMap>)` to
Python, allowing users to infer contraction dimensions (batch/m/n/k)
directly from a list of affine maps without needing an operation.
---------
Signed-off-by: Bangtian Liu <liubangtian@gmail.com>
|
|
Mostly mechanical changes to add the missing field.
|
|
performance-unnecessary-copy-initialization in Linalg.cpp (NFC)
|
|
(#156624)
This commit moves the "element" param of `DICompositeType` to the end of
the parameter list. This is required as there seems to be a bug in the
attribute parser that breaks a print + parse roundtrip.
Related ticket: https://github.com/llvm/llvm-project/issues/156623
|
|
This thread through proper error handling / reporting capabilities to
avoid hitting llvm_unreachable while parsing linalg ops.
Fixes #132755
Fixes #132740
Fixes #129185
|
|
(#136054)
This PR is mainly about exposing the python bindings for
`linalgOp.getIndexingMaps`.
---------
Signed-off-by: Bangtian Liu <liubangtian@gmail.com>
|
|
This PR adds "rich" python bindings to SMT dialect.
|
|
This PR upstreams/adds the C APIs for SMT dialect (from CIRCT).
---------
Co-authored-by: Bea Healy <beahealy22@gmail.com>
Co-authored-by: Martin Erhart <maerhart@outlook.com>
Co-authored-by: Mike Urbach <mikeurbach@gmail.com>
Co-authored-by: Will Dietz <will.dietz@sifive.com>
Co-authored-by: fzi-hielscher <hielscher@fzi.de>
Co-authored-by: Fehr Mathieu <mathieu.fehr@gmail.com>
Co-authored-by: Clo91eaf <Clo91eaf@qq.com>
|
|
linalg::isaConvolutionOpInterface and linalg::inferConvolutionDims (#135253)
This PR is mainly about exposing the python bindings for
`linalg::isaConvolutionOpInterface` and `linalg::inferConvolutionDims`.
---------
Signed-off-by: Bangtian Liu <liubangtian@gmail.com>
|
|
linalg::isaContractionOpInterface and linalg::inferContractionDims (#134935)
This PR is mainly about exposing the python bindings for`
linalg::isaContractionOpInterface` and` linalg::inferContractionDims`.
---------
Signed-off-by: Bangtian Liu <liubangtian@gmail.com>
|
|
This is an implementation for [RFC: Supporting Sub-Channel Quantization
in
MLIR](https://discourse.llvm.org/t/rfc-supporting-sub-channel-quantization-in-mlir/82694).
In order to make the review process easier, the PR has been divided into
the following commit labels:
1. **Add implementation for sub-channel type:** Includes the class
design for `UniformQuantizedSubChannelType`, printer/parser and bytecode
read/write support. The existing types (per-tensor and per-axis) are
unaltered.
2. **Add implementation for sub-channel type:** Lowering of
`quant.qcast` and `quant.dcast` operations to Linalg operations.
3. **Adding C/Python Apis:** We first define he C-APIs and build the
Python-APIs on top of those.
4. **Add pass to normalize generic ....:** This pass normalizes
sub-channel quantized types to per-tensor per-axis types, if possible.
A design note:
- **Explicitly storing the `quantized_dimensions`, even when they can be
derived for ranked tensor.**
While it's possible to infer quantized dimensions from the static shape
of the scales (or zero-points) tensor for ranked
data tensors
([ref](https://discourse.llvm.org/t/rfc-supporting-sub-channel-quantization-in-mlir/82694/3)
for background), there are cases where this can lead to ambiguity and
issues with round-tripping.
```
Consider the example: tensor<2x4x!quant.uniform<i8:f32:{0:2, 0:2}, {{s00:z00, s01:z01}}>>
```
The shape of the scales tensor is [1, 2], which might suggest that only
axis 1 is quantized. While this inference is technically correct, as the
block size for axis 0 is a degenerate case (equal to the dimension
size), it can cause problems with round-tripping. Therefore, even for
ranked tensors, we are explicitly storing the quantized dimensions.
Suggestions welcome!
PS: I understand that the upcoming holidays may impact your schedule, so
please take your time with the review. There's no rush.
|
|
|
|
cc @ftynse @wsmoses
|
|
|
|
This reverts commit 7ae964c55b0a2b8dccf076ced9f1ffa8d5487eca.
Revert "[mlir] Fix warnings"
This reverts commit 0e43b9547d56762d29de9a99c998e7939417a1f3.
|
|
|
|
Added C API functions for the EmitC dialect types.
|
|
|
|
|
|
Added EmitC dialect bindings.
|
|
LLVM already supports `DW_TAG_LLVM_annotation` entries for subprograms,
but this hasn't been surfaced to the LLVM dialect.
I'm doing the minimal amount of work to support string-based
annotations, which is useful for attaching metadata to
functions, which is useful for debuggers to offer features beyond basic
DWARF.
As LLVM already supports this, this patch is not controversial.
|
|
|
|
Full revamp of the 'quant' dialect. This is an implementation for the
RFC at
https://discourse.llvm.org/t/rfc-improvements-in-the-quant-dialect/79942
|
|
(#106947)
This reverts commit fa93be4, restoring
commit d884b77, with fixes that ensure the CAPI declarations are
exported properly.
This commit implements LLVM_DIRecursiveTypeAttrInterface for the
DISubprogramAttr to ensure cyclic subprograms can be imported properly.
In the process multiple shortcuts around the recently introduced
DIImportedEntityAttr can be removed.
|
|
Reverts llvm/llvm-project#106571
This commit breaks the following build bot:
https://lab.llvm.org/buildbot/#/builders/138/builds/2992
It looks like there is a missing dependency in this particular setup.
|
|
This commit implements LLVM_DIRecursiveTypeAttrInterface for the
DISubprogramAttr to ensure cyclic subprograms can be imported properly.
In the process multiple shortcuts around the recently introduced
DIImportedEntityAttr can be removed.
|
|
objects (#95292)
This patch adds the `#gpu.kernel_metadata` and `#gpu.kernel_table`
attributes. The `#gpu.kernel_metadata` attribute allows storing metadata
related to a compiled kernel, for example, the number of scalar
registers used by the kernel. The attribute only has 2 required
parameters, the name and function type. It also has 2 optional
parameters, the arguments attributes and generic dictionary for storing
all other metadata.
The `#gpu.kernel_table` stores a table of `#gpu.kernel_metadata`,
mapping the name of the kernel to the metadata.
Finally, the function `ROCDL::getAMDHSAKernelsELFMetadata` was added to
collect ELF metadata from a binary, and to test the class methods in
both attributes.
Example:
```mlir
gpu.binary @binary [#gpu.object<#rocdl.target<chip = "gfx900">, kernels = #gpu.kernel_table<[
#gpu.kernel_metadata<"kernel0", (i32) -> (), metadata = {sgpr_count = 255}>,
#gpu.kernel_metadata<"kernel1", (i32, f32) -> (), arg_attrs = [{llvm.read_only}, {}]>
]> , bin = "BLOB">]
```
The motivation behind these attributes is to provide useful information
for things like tunning.
---------
Co-authored-by: Mehdi Amini <joker.eph@gmail.com>
|
|
The `DIImporedEntity` can be used to represent imported entities like
C++'s namespace with using directive or fortran's moudule with use
statement.
This PR adds `DIImportedEntityAttr` and 2-way translation from
`DIImportedEntity` to `DIImportedEntityAttr` and vice versa.
When an entity is imported in a function, the `retainedNodes` field of
the `DISubprogram` contains all the imported nodes. See the C++ code and
the LLVM IR below.
```
void test() {
using namespace n1;
...
}
!2 = !DINamespace(name: "n1", scope: null)
!16 = distinct !DISubprogram(name: "test", ..., retainedNodes: !19) !19 = !{!20}
!20 = !DIImportedEntity(tag: DW_TAG_imported_module, scope: !16, entity: !2 ...)
```
This PR makes sure that the translation from mlir to `retainedNodes`
field happens correctly both ways.
To side step the cyclic dependency between `DISubprogramAttr` and `DIImportedEntityAttr`,
we have decided to not have `scope` field in the `DIImportedEntityAttr` and it is inferred
from the entity which hold the list of `DIImportedEntityAttr`. A `retainedNodes` field has been
added in the `DISubprogramAttr` which contains the list of `DIImportedEntityAttr` for that
function.
This PR currently does not handle entities imported in a global scope
but that should be easy to handle in a subsequent PR.
|
|
|
|
This patch enables the use of flags for local variables in debug info.
They were defaulted as always zero, but allowing them is pretty trivial.
|
|
The PR adds py binding for `AsyncTokenType`
|
|
This PR handle translation of DIStringType. Mostly mechanical changes to
translate DIStringType to/from DIStringTypeAttr. The 'stringLength'
field is 'DIVariable' in DIStringType. As there was no `DIVariableAttr`
previously, it has been added to ease the translation.
---------
Co-authored-by: Tobias Gysi <tobias.gysi@nextsilicon.com>
|
|
The fortran arrays use 'dataLocation', 'rank', 'allocated' and
'associated' fields of the DICompositeType. These were not available in
'DICompositeTypeAttr'. This PR adds the missing fields.
---------
Co-authored-by: Tobias Gysi <tobias.gysi@nextsilicon.com>
|
|
This field is present in LLVM, but was missing from the MLIR wrapper
type. This addition allows MLIR languages to add proper DWARF info for
GPU programs.
|
|
Being able to add custom dialects is one of the big missing pieces of
the C API. This change should make it achievable via IRDL. Hopefully
this should open custom dialect definition to non-C++ users of MLIR.
|
|
1. Explicit value means the non-zero value in a sparse tensor. If
explicitVal is set, then all the non-zero values in the tensor have the
same explicit value. The default value Attribute() indicates that it is
not set.
2. Implicit value means the "zero" value in a sparse tensor. If
implicitVal is set, then the "zero" value in the tensor is equal to the
implicit value. For now, we only support `0` as the implicit value but
it could be extended in the future. The default value Attribute()
indicates that the implicit value is `0` (same type as the tensor
element type).
Example:
```
#CSR = #sparse_tensor.encoding<{
map = (d0, d1) -> (d0 : dense, d1 : compressed),
posWidth = 64,
crdWidth = 64,
explicitVal = 1 : i64,
implicitVal = 0 : i64
}>
```
Note: this PR tests that implicitVal could be set to other values as
well. The following PR will add verifier and reject any value that's not
zero for implicitVal.
|
