This repository was archived by the owner on Oct 11, 2025. It is now read-only.
[LLVM] Integrate to 49f20934776c#3
Closed
bump-llvm[bot] wants to merge 915 commits intomainfrom
Closed
Conversation
1. C++ enum is set through enum class LevelType : uint_64. 2. C enum is set through typedef uint_64 level_type. It is due to the limitations in Windows build: setting enum width to ui64 is not supported in C.
1. Add parsing methods for block[n, m]. 2. Encode n and m with the newly extended 64-bit LevelType enum. 3. Update 2:4 methods names/comments to n:m.
…663)
Currently, a method exists to get the count of the operation objects
which are still alive. This helps for sanity checking, but isn't
terribly useful for debugging. This new method returns the actual
operation objects which are still alive.
This allows Python code like the following:
```
gc.collect()
live_ops = ir.Context.current._get_live_operation_objects()
for op in live_ops:
print(f"Warning: {op} is still live. Referrers:")
for referrer in gc.get_referrers(op)[0]:
print(f" {referrer}")
```
1. Add python test for n out of m 2. Add more methods for python binding 3. Add verification for n:m and invalid encoding tests 4. Add e2e test for n:m Previous PRs for n:m #80501 #79935
…ion class (#81424)
…… (#81682) …ct LevelType from LevelFormat and properties instead. **Rationale** We used to explicitly declare every possible combination between `LevelFormat` and `LevelProperties`, and it now becomes difficult to scale as more properties/level formats are going to be introduced.
… (#81720) This allows to * check if a given ir.Type is a floating point type via isinstance() or issubclass() * get the bitwidth of a floating point type See motivation and discussion in https://discourse.llvm.org/t/add-floattype-to-mlir-python-bindings/76959.
Expose the API for constructing and inspecting StructTypes from the LLVM dialect. Separate constructor methods are used instead of overloads for better readability, similarly to IntegerType.
…… (#81799) …ormat and properties instead.
…m LevelF…" (#81923) Reverts llvm/llvm-project#81799 ; this broke the mlir gcc7 bot.
…om LevelFormat and Properties" (#81923) (#81934)
Transform interpreter functionality can be used standalone without going through the interpreter pass, make it available in Python.
_SubClassValueT is only useful when it is has >1 usage in a signature.
This was not true for the signatures produced by tblgen.
For example
def call(result, callee, operands_, *, loc=None, ip=None) ->
_SubClassValueT:
...
here a type checker does not have enough information to infer a type
argument for _SubClassValueT, and thus effectively treats it as Any.
…ntation (#82094) This decouples the public API used to enqueue tasks and wait for completion from the actual implementation, and opens up the possibility for clients to set their own thread pool implementation for the pool. https://discourse.llvm.org/t/construct-threadpool-from-vector-of-existing-threads/76883
move constructors should be marked noexcept
Arithmetic constants for vector types can be constructed from objects implementing Python buffer protocol such as `array.array`. Note that until Python 3.12, there is no typing support for buffer protocol implementers, so the annotations use array explicitly.
The base class llvm::ThreadPoolInterface will be renamed llvm::ThreadPool in a subsequent commit. This is a breaking change: clients who use to create a ThreadPool must now create a DefaultThreadPool instead.
…84103) Reverts llvm/llvm-project#83259 This broke an integration test on Windows
LLVM does not have the corresponding ClangTidy check enabled, so we should not be fixing such findings.
…#84142) Arithmetic constants for vector types can be constructed from objects implementing Python buffer protocol such as `array.array`. Note that until Python 3.12, there is no typing support for buffer protocol implementers, so the annotations use array explicitly. Reverts llvm/llvm-project#84103
This PR adds the following to the mlir c api: - The disctinct mlir builtin attribute. - LLVM attributes (mostly debug related ones)
Following the discussion from [this thread](https://discourse.llvm.org/t/handling-cyclic-dependencies-in-debug-info/67526/11), this PR adds support for recursive DITypes. This PR adds: 1. DIRecursiveTypeAttrInterface: An interface that DITypeAttrs can implement to indicate that it supports recursion. See full description in code. 2. Importer & exporter support (The only DITypeAttr that implements the interface is DICompositeTypeAttr, so the exporter is only implemented for composites too. There will be two methods that each llvm DI type that supports mutation needs to implement since there's nothing general). --------- Co-authored-by: Tobias Gysi <tobias.gysi@nextsilicon.com>
This commit extends the DIDerivedTypeAttr with the `extraData` field. For now, the type of it is limited to be a `DINodeAttr`, as extending the debug metadata handling to support arbitrary metadata nodes does not seem to be necessary so far.
This small patch enables python bindings for the index dialect. --------- Co-authored-by: Steven Varoumas <steven.varoumas1@huawei.com>
Transform interfaces are implemented, direction or via extensions, in libraries belonging to multiple other dialects. Those dialects don't need to depend on the non-interface part of the transform dialect, which includes the growing number of ops and transitive dependency footprint. Split out the interfaces into a separate library. This in turn requires flipping the dependency from the interface on the dialect that has crept in because both co-existed in one library. The interface shouldn't depend on the transform dialect either. As a consequence of splitting, the capability of the interpreter to automatically walk the payload IR to identify payload ops of a certain kind based on the type used for the entry point symbol argument is disabled. This is a good move by itself as it simplifies the interpreter logic. This functionality can be trivially replaced by a `transform.structured.match` operation.
…(#87223) The ``dataclasses`` package makes sense for Python 3.6, becauses ``dataclasses`` is only included in the standard library with 3.7 version. Now, 3.6 has reached EOL, so all current supported versions of Python (3.8, 3.9, 3.10, 3.11, 3.12) have this feature in their standard libraries. Therefore there's no need to install the ``dataclasses`` package now.
Add the DebugNameTableKind field to DICompileUnit, along with its importer & exporter.
This thread through proper error handling / reporting capabilities to avoid hitting llvm_unreachable while parsing linalg ops. Fixes #132755 Fixes #132740 Fixes #129185
DenseMapInfo for pointers currently uses empty/tombstone values that are aligned (by assuming a very conservative alignment). However, this means that we have to work with larger immediates. This patch proposes to use the values -1 and -2 instead, without caring about pointer alignment. (Non-roundtrip) integer to pointer casts are implementation-defined in C++, but the general implementer consensus (including Clang) is that raw pointers do not carry alignment requirements, only memory accesses do. We already have lots of places that rely on this using variations on `reinterpret_cast<T*>(-1)`, so it seems odd to insist on properly aligned pointers in this one place. It is necessary to adjust a few other places after this change, which currently assume that `DenseMapInfo<void *>` returns a highly-aligned pointer. This is a small improvement for both compile-time and clang binary size.
RFC: https://discourse.llvm.org/t/rfc-deprecate-linalg-elemwise-unary-and-elemwise-binary/87144 Remove the two operations and fix the tests by: * Cleaning simple operation tests of the old ops * Changing `linalg.elemwise_{u|bi}nary` with `linalg.{exp|add}` on transform tests * Changing some of the tests with `linalg.elementwise` instead, to broaden test coverage * Surgically removing the `elemwise_*` part in the Python tests * Update MLIR transform examples (text and tests) with `linalg.elementwise` instead Nothing else changed.
This reverts commit bdbf563. This causes ubsan failures when the sentinel pointers are upcast using static_cast<>, which checks alignment.
The motivation is to avoid having to negate `isDynamic*` checks, avoid double negations, and allow for `ShapedType::isStaticDim` to be used in ADT functions without having to wrap it in a lambda performing the negation. Also add the new functions to C and Python bindings.
A new transform op to represent that an attribute is to be chosen from a set of alternatives and that this choice is made available as a `!transform.param`. When a `selected` argument is provided, the op's `apply()` semantics is that of just making this selected attribute available as the result. When `selected` is not provided, `apply()` complains that nothing has resolved the non-determinism that the op is representing.
…pt (#143866) This is mentioned as a "must" in https://nanobind.readthedocs.io/en/latest/porting.html#type-casters when implementing type casters. While most of the existing `from_cpp` methods were already marked noexcept, many of the `from_python` methods were not. This commit adds the missing noexcept declarations to all type casters found in `NanobindAdaptors.h`. --------- Co-authored-by: Maksim Levental <maksim.levental@gmail.com>
After #143866, we no longer always write to `value`, causing it to be uninitialized. This can lead to mysterious crashes, e.g. in `python_test.py` / `testCustomAttribute` when we attempt to evaluate `TestAttr(42)`, it does not set `value`, but `mlirAttributeIsNull(value)` happens to return false for garbage memory, and we end up trying to interpret it as a function instead of skipping it. Fix this by only reading `value` if it has been assigned. If it hasn't, `return false` seems the right choice for all these methods, i.e. indicate that `from_python` failed.
…(#149187) - Introduces a `large_resource_limit` parameter across Python bindings, enabling the eliding of resource strings exceeding a specified character limit during IR printing. - To maintain backward compatibilty, when using `operation.print()` API, if `large_resource_limit` is None and the `large_elements_limit` is set, the later will be used to elide the resource string as well. This change was introduced by llvm/llvm-project#125738. - For printing using pass manager, the `large_resource_limit` and `large_elements_limit` are completely independent of each other.
This patch specializes the Python bindings for ForallOp and InParallelOp, similar to the existing one for ForOp. These bindings create the regions and blocks properly and expose some additional helpers.
This PR melds llvm/llvm-project#150137 and llvm/llvm-project#149414 *and* partially reverts llvm/llvm-project#124832. The summary is the `PyDenseResourceElementsAttribute` finalizer/deleter has/had two problems 1. wasn't threadsafe (can be called from a different thread than that which currently holds the GIL) 2. can be called while the interpreter is "not initialized" llvm/llvm-project#124832 for some reason decides to re-initialize the interpreter to avoid case 2 and runs afoul of the fact that `Py_IsInitialized` can be false during the finalization of the interpreter itself (e.g., at the end of a script). I don't know why this decision was made (I missed the PR) but I believe we should never be calling [Py_Initialize](https://docs.python.org/3/c-api/init.html#c.Py_Initialize): > In an application \*\*\*\***embedding Python**\*\*\*\*, this should be called before using any other Python/C API functions **but we aren't embedding Python**! So therefore we will only be in case 2 when the interpreter is being finalized and in that case we should just leak the buffer. Note, [lldb](https://github.com/llvm/llvm-project/blob/548ca9e97673a168023a616d311d901ca04b29a3/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp#L81-L93) does a similar sort of thing for its finalizers. Co-authored-by: Anton Korobeynikov <anton@korobeynikov.info> Co-authored-by: Max Manainen <maximmanainen@gmail.com> Co-authored-by: Anton Korobeynikov <anton@korobeynikov.info> Co-authored-by: Max Manainen <maximmanainen@gmail.com>
…150805) `InitAll***` functions are used by `opt`-style tools to init all MLIR dialects/passes/extensions. Currently they are implemeted as inline functions and include essentially the entire MLIR header tree. Each file which includes this header (~10 currently) takes 10+ sec and multiple GB of ram to compile (tested with clang-19), which limits amount of parallel compiler jobs which can be run. Also, flang just includes this file into one of its headers. Move the actual registration code to the static library, so it's compiled only once. Discourse thread https://discourse.llvm.org/t/rfc-moving-initall-implementation-into-static-library/87559
…rary." (#151118) Reverts llvm/llvm-project#150805 Some bots are failing.
…151150) Reland llvm/llvm-project#150805 Shared libs build was broken. Add `${dialect_libs}` and `${conversion_libs}` to `MLIRRegisterAllExtensions` because it depends on `registerConvert***ToLLVMInterface` functions.
Removes the `(batch_)matmul_transpose_{a|b}` variants from OpDSL and
replace it with `matmul affine_maps [...]` whenever appropriate. This is
in line with the
[plan](https://discourse.llvm.org/t/rfc-op-explosion-in-linalg/82863),
and can be done since #104783 merged.
See:
https://discourse.llvm.org/t/deprecate-batch-matmul-transpose-a-b-linalg-operations/87245
Issues investigated:
* pad transform tests that could use `matmul` instead, so change to
that.
* ArmSME test using transpose actually needed it, so changed to `matmul`
+ affine maps.
Arm tests validated by @banach-space (thanks!!).
This PR implements "automatic" location inference in the bindings. The way it works is it walks the frame stack collecting source locations (Python captures these in the frame itself). It is inspired by JAX's [implementation](https://github.com/jax-ml/jax/blob/523ddcfbcad005deab5a7d542df4c706f5ee5e9c/jax/_src/interpreters/mlir.py#L462) but moves the frame stack traversal into the bindings for better performance. The system supports registering "included" and "excluded" filenames; frames originating from functions in included filenames **will not** be filtered and frames originating from functions in excluded filenames **will** be filtered (in that order). This allows excluding all the generated `*_ops_gen.py` files. The system is also "toggleable" and off by default to save people who have their own systems (such as JAX) from the added cost. Note, the system stores the entire stacktrace (subject to `locTracebackFramesLimit`) in the `Location` using specifically a `CallSiteLoc`. This can be useful for profiling tools (flamegraphs etc.). Shoutout to the folks at JAX for coming up with a good system. --------- Co-authored-by: Jacques Pienaar <jpienaar@google.com>
`PyThreadState_GetFrame` wasn't added until 3.9 (fixes currently failing rocm builder)
add more APIs missing from 3.8 (fix rocm builder)
…cit method call (#153373) This PR introduces a mechanism to defer JIT engine initialization, enabling registration of required symbols before global constructor execution. ## Problem Modules containing `gpu.module` generate global constructors (e.g., kernel load/unload) that execute *during* engine creation. This can force premature symbol resolution, causing failures when: - Symbols are registered via `mlirExecutionEngineRegisterSymbol` *after* creation - Global constructors exist (even if not directly using unresolved symbols, e.g., an external function declaration) - GPU modules introduce mandatory binary loading logic ## Usage ```c // Create engine without initialization MlirExecutionEngine jit = mlirExecutionEngineCreate(...); // Register required symbols mlirExecutionEngineRegisterSymbol(jit, ...); // Explicitly initialize (runs global constructors) mlirExecutionEngineInitialize(jit); ``` --------- Co-authored-by: Mehdi Amini <joker.eph@gmail.com>
…an explicit method call" (#153477) Reverts llvm/llvm-project#153373 Sanitizer bot is broken
bump-llvm
Bot
force-pushed
the
update-llvm
branch
from
22c3668 to
ca82ac6
Compare
auto-merge was automatically disabled
August 14, 2025 20:09
Pull request was closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Integrate LLVM to llvm/llvm-project@49f20934776c