Exposes `OperationEquivalence` through the MLIR C API so callers can compare operations structurally rather than by handle identity.
Assisted by: Claude
Share LLVM dialect metadata materialization through `ModuleTranslation`
so named metadata and metadata-as-value lowering use one conversion
path. Resolve metadata symbol references to functions, globals, aliases,
and ifuncs, and diagnose malformed required metadata before lowering.
Rename `MDFuncAttr` to `MDGlobalValueAttr` to reflect its support for
symbol-backed global values.
Exposes `Value::replaceUsesWithIf` through the MLIR C API, allowing callers to replace only a subset of a value's uses based on a predicate.
Assisted by: Claude
Exposes `OpBuilder::saveInsertionPoint` / `restoreInsertionPoint` through the MLIR C API for `MlirRewriterBase`, continuing the buildout of the rewrite/conversion C bindings.
Assisted by: Claude
This PR adds dynamic `IsIsolatedFromAbove` trait support and exposes it
to Python as `IsIsolatedFromAboveTrait`.
The test verifies that a region with the trait cannot capture an SSA
value from above, while a region without the trait can.
Assisted by Codex/GPT 5.6 Sol (for writing test cases).
Python-defined dialect loading currently relies on
`Dialect._mlir_module` to infer whether a dialect has already been
loaded. This state belongs to the Python dialect class rather than an
MLIR context.
Consequently, loading the same dialect after switching contexts requires
`reload=True`, while reloading it in a context where it is already
present can hit the operation registration assertion reported in
#210053.
This patch adds `mlirContextGetLoadedDialect` (following
https://github.com/llvm/lighthouse/pull/228#discussion_r3589792891) to
the C API and exposes it as `Context.is_dialect_loaded`.
`Dialect.load()` now queries the active context:
- loading a dialect more than once in the same context raises a
`RuntimeError`;
- loading the same Python-defined dialect in another context succeeds
without a `reload` flag.
The `reload` parameter is semantically wrong (mentioned in
https://github.com/llvm/lighthouse/pull/228#discussion_r3586672116) thus
removed from the API as a small breaking change. Usually, users who are
using `reload` can just remove it and everything will work fine.
Fixes#210053.
Assisted by GPT 5.6 Sol (for writing test cases).
Python implementations of `MemoryEffectsOpInterface` receive a
`MemoryEffectInstancesList` (added in #176920), but currently have no
generic way to populate it.
This adds the C API for constructing and appending memory effect
instances and exposes it in Python through `MemoryEffect`,
`SideEffectResource`, and `MemoryEffectInstancesList.append`. The tests
use CSE and DCE to verify that the declared effects are observed by MLIR
passes.
Assisted-by: GPT 5.6 Sol
Builds on the source/target materialization C bindings (#208934) to
expose the 1:N dialect-conversion functionality through the MLIR C API.
Continues the buildout of the dialect-conversion C bindings (follows
#206146 and #206161).
Assisted by: Claude
Continues the buildout of the dialect-conversion C bindings (follows
#206146 and #206161).
- Exposes `TypeConverter::addSourceMaterialization` and
`addTargetMaterialization` through the MLIR C API.
- Introduces `MlirTypeConverterConversionStatus`
(`Success`/`Failure`/`Declined`) and switches
`MlirTypeConverterConversionCallback` to return it, replacing the old
`MlirLogicalResult` + `MlirType{NULL}` dual sentinel. The old convention
could not distinguish the C++ decline (`std::nullopt`, try the next
conversion) and hard-failure (`failure()`, stop) states; the enum maps
cleanly to all three. The Python binding and C API test are updated
accordingly.
Assisted by: Claude
Fixes LeakSanitizer failure from #206161 (reverted in #207104);
`mlirFreezeRewritePattern` moves contents out of the `RewritePatternSet`
but does not free the container (passed by value in the C API), so the
allocation from `mlirRewritePatternSetCreate` was never freed (add
`mlirRewritePatternSetDestroy(patterns)` after freezing).
Add `mlirConversionTargetAddDynamicallyLegalOp`,
`mlirConversionTargetAddDynamicallyLegalDialect`,
`mlirConversionTargetMarkOpRecursivelyLegal`, and
`mlirConversionTargetMarkUnknownOpDynamicallyLegal` to enable
per-instance legality callbacks from C.
Assisted by: Claude
Expose DominanceInfo and PostDominanceInfo through the MLIR C API with
operation/block/value dominance queries, nearest common dominator,
reachability, and invalidation.
Assisted by: Claude
Expose IRMapping through the MLIR C API with full create/destroy/map, lookup, contains/erase, and clone-with-mapping functionality.
Assisted by: Claude
This PR adds an overload of `inferConvolutionDims` that takes only
indexing maps (input, filter, output), mirroring the maps-based
`inferContractionDims` overload added in #76081, along with the
corresponding C API and python bindings.
Assisted by: Claude-code
This PR brings two features: the `ConditionallySpeculatable` op
interface and the `Pure` specifier for Python-defined ops.
The result is that you can mark an op as pure like:
```python
class PureOp(
TestPure.Operation,
name="pure",
traits=[Pure] # just like in the ODS!
):
a: Operand[IntegerType[32]]
b: Operand[IntegerType[32]]
res: Result[IntegerType[32]] = infer_result()
```
Then this op is both `NoMemoryEffect` and `AlwaysSpeculatable`.
Assisted-by: Copilot/GPT5.4
#### Summary
This PR extends the MLIR LLVM dialect debug-info attributes to represent
DWARF variant parts, discriminators, and per-alternative discriminator
values.
The change adds `identifier` and `discriminator` support to
`DICompositeTypeAttr`, allowing MLIR to model `DW_TAG_variant_part`
metadata that LLVM IR already supports. It also broadens
`DIDerivedTypeAttr`'s `extraData` field from `DINodeAttr` to a verified
polymorphic `Attribute`, supporting both debug-info nodes and integer
constants used by variant alternatives.
#### Details
- Add `identifier` and `discriminator` fields to `DICompositeTypeAttr`,
bytecode serialization, LLVM IR import/export, C API bindings, and Flang
call sites.
- Change `DIDerivedTypeAttr.extraData` to accept either `DINodeAttr` or
`IntegerAttr`, with verifier coverage for invalid attribute kinds.
- Preserve integer bit width when importing
`ConstantAsMetadata(ConstantInt)` into MLIR.
- Add parse/print, verifier, LLVM IR import/export, and C API test
coverage for variant-part debug info.
---------
Co-authored-by: Tobias Gysi <tobias.gysi@nextsilicon.com>
Addresses #53169. Mirrors the Python bindings pattern used for Attribute
subclasses so that Location discrimination uses `isinstance`, and fills
two small gaps at the same time.
### Approach
Previously `Location` was a single nanobind class with `is_a_file`,
`is_a_name`, etc. predicates, plus field accessors for every kind
defined on the base class. This PR introduces a `PyConcreteLocation<T>`
CRTP template (parallel to `PyConcreteAttribute<T>`) and registers one
subclass per `LocationAttr` kind: `UnknownLoc`, `FileLineColLoc`,
`NameLoc`, `CallSiteLoc`, `FusedLoc`.
TypeID-based downcasting is implemented in `PyLocation::maybeDownCast`
(using `mlirAttributeGetTypeID(mlirLocationGetAttribute(...))`) and
called at the boundaries that return Location objects: `op.location`,
`value.location`, `Location.from_attr`, and the subclass getters
themselves.
### Example
```python
from mlir.ir import Context, Module, FileLineColLoc, NameLoc, FusedLoc
with Context():
module = Module.parse("...")
for op in module.body.operations:
loc = op.location
if isinstance(loc, FileLineColLoc):
report(f"{loc.filename}:{loc.start_line}:{loc.start_col}")
elif isinstance(loc, NameLoc):
report(loc.name_str)
elif isinstance(loc, FusedLoc) and loc.metadata is not None:
report_fused(loc.locations, loc.metadata)
```
`FusedLoc.metadata` is also newly exposed (the underlying C API
`mlirLocationFusedGetMetadata` already existed but was not bound).
### Custom/downstream Location classes
`PyConcreteLocation<DerivedTy>` is marked `MLIR_PYTHON_API_EXPORTED` and
is used identically to `PyConcreteAttribute<DerivedTy>`. Downstream
projects that define their own `LocationAttr` in C++ expose a matching
Python class by declaring a subclass with the standard statics
(`isaFunction`, `pyClassName`, optional `getTypeIdFunction`) and calling
its `bind(m)` at module init; `isinstance` and automatic downcasting
then work with no further changes in the base bindings.
### Backward compatibility
Existing factories — `Location.unknown()`, `Location.file(...)`,
`Location.name(...)`, `Location.callsite(...)`, `Location.fused(...)` —
remain as aliases and now return the concrete subclass instance (so
`isinstance(Location.file(...), FileLineColLoc)` is true). No user
migration is required for construction.
The old `is_a_*` predicate methods are removed; downstream consumers
should switch to `isinstance(...)`. No in-tree users of the removed
predicates besides the existing Location tests, which have been
rewritten accordingly.
### Scope note — OpaqueLoc
OpaqueLoc is intentionally not included. It is keyed on a C++
`TypeID::get<T>()` tag that has no natural Python counterpart, and I
could not find a downstream consumer asking for Python exposure. An
earlier revision of this PR exposed it with an `id(obj)` + `ctypes.cast`
example, but that pattern is lifetime-unsafe (MLIR does not INCREF the
underlying pointer) and the C++ `getUnderlyingLocation<T>()` semantics
don't translate cleanly. Happy to add it in a follow-up once a real use
case surfaces.
### Changes
C API (`mlir/include/mlir-c/IR.h`, `mlir/lib/CAPI/IR/IR.cpp`):
- `mlirLocationIsAUnknown`, `mlirLocationUnknownGetTypeID` — other
Location kinds already had their `IsA*`/`*GetTypeID` pair.
Python (`mlir/include/mlir/Bindings/Python/IRCore.h`,
`mlir/lib/Bindings/Python/IRCore.cpp`):
- `PyConcreteLocation<T>` template and five concrete classes
- `PyLocation::maybeDownCast`
- Subclass `.get()` constructors, `.metadata` on `FusedLoc`
Tests:
- `mlir/test/python/ir/location.py` rewritten around `isinstance` and
subclass construction; adds explicit-cast-failure coverage.
- `mlir/test/CAPI/ir.c` adds `testLocation` covering the new
`mlirLocationIsAUnknown` predicate.
### Tool-use disclosure
This change was drafted with Claude (Anthropic) assistance per LLVM's
[AI Tool Use Policy](https://llvm.org/docs/AIToolPolicy.html). All code
was read, reviewed, and tested locally by me; the commit carries
`Assisted-by:` and `Co-Authored-By:` trailers accordingly.
---------
Co-authored-by: Claude (Anthropic) <noreply@anthropic.com>
This PR add `DIRecursiveTypeAttrInterface` to `DICompileUnitAttr`. It
should fix the circular dependency problem we have since
`importedEntities` field was added.
This PR adds a `has_trait(trait_cls)` API to `_OperationBase`, that can
be used for:
- C++-defined operations and C++-defined traits (e.g.
`func_return_op.has_trait(IsTerminatorTrait)`)
- Python-defined operations and C++-defined traits (e.g.
`my_python_op.has_trait(IsTerminatorTrait)`)
- Python-defined operations and Python-defined traits (e.g.
`my_python_op.has_trait(MyPythonTrait)`)
---------
Co-authored-by: Maksim Levental <maksim.levental@gmail.com>
Added support for option "-fdebug-info-for-profiling" in flang.
- When the option `-fdebug-info-for-profiling` option is passed,
compiler sets the `DebugInfoForProfiling` flag and triggers the
`AddDiscriminatorsPass`. This pass inserts additional debug metadata,
specifically discriminator values into the IR to improve the profiling
precision.
- Additionally `-add-debug-info` pass has been updated to emit an extra
field, `debugInfoForProfiling: true` inside the generated DICompileUnit
metadata node.
Previously, the MLIR's python binding `smt.export_smtlib(...)` always
emit `(reset)` to the end of smtlib string as a solver terminator.
This PR added an option to suppress this trailing, as downstream users
like python z3 module don't need it.
This PR adds some LLVM metadata attributes and an `llvm.named_metadata`
container op (similar to `llvm.module_flags`) for those attributes.
Summary:
- Add MLIR attributes modeling LLVM IR metadata: `#llvm.md_string`,
`#llvm.md_const`, `#llvm.md_func`, and `#llvm.md_node`;
- Add `llvm.named_metadata` container op for module-level named metadata
nodes;
- Add MLIR-to-LLVM-IR translation for the new attributes and op;
- Add C API functions (`mlirLLVMMDStringAttrGet`,
`mlirLLVMMDNodeAttrGet`, etc.);
- Add Python bindings (`llvm.MDStringAttr`, `llvm.MDConstantAttr`,
`llvm.MDFuncAttr`, `llvm.MDNodeAttr`, `llvm.FunctionType`).
`DenseIntOrFPElementsAttr` was recently generalized to accept any type
that implement the `DenseElementType` interface. The name
`DenseIntOrFPElementsAttr` does not make sense anymore. This commit
renames the attribute to `DenseTypedElementsAttr`. An alias is kept for
migration purposes. The alias will be removed after some time.
This PR updates `DIDerivedTypeAttr` to support optional file, line and
scope parameters in the same way as `DICompositeTypeAttr`. These
parameters are already supported in the `llvm::DIDerivedType`
constructor and were hardcoded to nullptr/0, they are now accessible
from MLIR.
The existing `llvmir-debug.mlir` test has been updated to test these
changes.
Makes it possible to include Python-defined rewrite patterns in
transform-dialect schedules, inside of `transform.apply_patterns`, which
upon execution of the schedule runs the pattern in a greedy rewriter.
With assistance of Claude.
Unifies the two dialects that define x86 operations into a single one.
The AMX dialect is moved into X86 in line with other x86 extensions.
Following the dialect renaming, X86 dialect is now a suitable home for
wider range of operations targeting specific hardware features. Moving
AMX definitions to X86 dialect creates a single, centralized hub for
defining all x86 intrinsic-like operations. The new grouping aims to
eliminate the need for new dialects as new hardware extensions become
available.
The two dialects are simply merged together. X86 dialect refactoring
will be addressed separately.
List of changes:
- operations: 'amx.tile_*' => 'x86.amx.tile_*'
- types: '!amx.tile' => '!x86.amx.tile'
- namespace: 'mlir::amx' => 'mlir::x86::amx'
- test define: 'MLIR_RUN_AMX_TESTS' => 'MLIR_RUN_X86_AMX_TESTS'
- vector lowering: AMX is enabled by default together with X86
The MLIR AMX tests are now nested under X86 directory. To enable AMX
integration tests, 'MLIR_RUN_X86_TESTS' must also be defined.
This PR adds the `convert_region_types` API to
`ConversionPatternRewriter` and introduces a new integration test,
`bf.py`, which demonstrates how to combine a Python-defined dialect, the
dialect conversion API, the pass manager, and the execution engine to
build a pure-Python JIT compilation pipeline.
Renames 'x86vector' dialect to 'x86'.
This is the first PR in series of cleanups around dialects targeting x86
platforms.
The new naming scheme is shorter, cleaner, and opens possibility of
integrating other x86-specific operations not strictly fitting pure
vector representation. For example, the generalization will allow for
future merger of AMX dialect into the x86 dialect to create one-stop x86
operations collection and boost discoverability.
Previously, we were using the static `typeid` of `DynamicType` for
checks, which is incorrect. We should instead check against the `typeid`
of `DynamicTypeDefinition` (which is a subclass of `SelfOwningTypeID`),
and register it via `register_type_caster` so that Python-defined types
can use `maybe_downcast`. (The attribute part is same.)
This PR adds C and Python API support for `mlir::DynamicAttr`. It
primarily enables attributes in dialects that are dynamically generated
via IRDL to be constructed in Python, and allows retrieving the
parameters contained in a dynamic attribute from Python.
This PR is quite similiar to #182751, so I use tab to autocomplete some
code via github copilot, but manually verified.
This PR adds C and Python API support for `mlir::DynamicType`. It
primarily enables types in dialects that are dynamically generated via
IRDL to be constructed in Python, and allows retrieving the parameters
contained in a dynamic type from Python.
---------
Co-authored-by: Rolf Morel <rolfmorel@gmail.com>
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 completed work from
https://github.com/llvm/llvm-project/pull/178290.
Switched the last few python bindings that still relied on LLVM over to
the C API, and dropped `LLVMsupport` dependency from MLIR cmake.
This is a follow-up PR of #169045 and the second part of #179086.
In #179086, we added support for defining regions in Python-defined ops,
but its usefulness was quite limited because we still couldn’t mark an
op as a `Terminator` or `NoTerminator`. In this PR, we port the
`DynamicOpTrait` (introduced on the C++ side for `DynamicDialect` in
#177735) to Python, so we can dynamically attach traits to
Python-defined ops.
This PR adds a C API `MlirLlvmRawFdOstream` for `llvm::raw_fd_ostream`,
which cannot be safely replaced by `std::ofstream` on Windows.
`llvm::raw_fd_ostream` configures Win32 file sharing flags, allowing
other handles (e.g. Python temp file handles) to coexist, see details
[here](https://llvm.org/doxygen/Windows_2Path_8inc_source.html#l1281),
while `std::ofstream` disables file sharing by default.
This PR adds dialect conversion support to the MLIR Python bindings.
Because it introduces a number of new APIs, it’s a fairly large PR. It
mainly includes the following parts:
* Add a set of types and APIs to the C API, including
`MlirConversionTarget`, `MlirConversionPattern`, `MlirTypeConverter`,
`MlirConversionPatternRewriter`, and others.
* Add the corresponding types and APIs to the Python bindings.
* Extend `mlir-tblgen` with codegen for Python adaptor classes, which
generates an adaptor class for each op.
Note that this PR only adds support for 1-to-1 conversions, 1-to-N
type/value conversions are not supported yet.
---------
Co-authored-by: Maksim Levental <maksim.levental@gmail.com>
This PR extends the MLIR C API and Python bindings to support
**arbitrary-precision integers (`APInt`)**, overcoming the previous
limitation where `IntegerAttr` values were restricted to 64 bits.
Cryptographic applications often require integer types much larger than
standard machine words (e.g., the 256-bit modulus for the BN254 curve).
Previously, attempting to bind these values resulted in truncation or
errors. This PR exposes the underlying word-based `APInt` structure via
the C API and updates the Python bindings to seamlessly handle Python's
arbitrary-precision integers.
After #174756 I found that attribute name for `FloatAttr` is missing.
And this PR is to add it.
This is actually part of changes in #169045, but I think that we can
make it a separate PR to make #169045 easier to review.
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.
