#
6ce44266 |
| 08-Nov-2024 |
Kazu Hirata <kazu@google.com> |
[mlir] Use heterogenous lookups with std::map (NFC) (#115426)
Heterogenous lookups allow us to call find with StringRef, avoiding a
temporary heap allocation of std::string.
|
#
84cc1865 |
| 05-Aug-2024 |
Nikhil Kalra <nikhil.kalra@gmail.com> |
[mlir] Support DialectRegistry extension comparison (#101119)
`PassManager::run` loads the dependent dialects for each pass into the
current context prior to invoking the individual passes. If the
[mlir] Support DialectRegistry extension comparison (#101119)
`PassManager::run` loads the dependent dialects for each pass into the
current context prior to invoking the individual passes. If the
dependent dialect is already loaded into the context, this should be a
no-op. However, if there are extensions registered in the
`DialectRegistry`, the dependent dialects are unconditionally registered
into the context.
This poses a problem for dynamic pass pipelines, however, because they
will likely be executing while the context is in an immutable state
(because of the parent pass pipeline being run).
To solve this, we'll update the extension registration API on
`DialectRegistry` to require a type ID for each extension that is
registered. Then, instead of unconditionally registered dialects into a
context if extensions are present, we'll check against the extension
type IDs already present in the context's internal `DialectRegistry`.
The context will only be marked as dirty if there are net-new extension
types present in the `DialectRegistry` populated by
`PassManager::getDependentDialects`.
Note: this PR removes the `addExtension` overload that utilizes
`std::function` as the parameter. This is because `std::function` is
copyable and potentially allocates memory for the contained function so
we can't use the function pointer as the unique type ID for the
extension.
Downstream changes required:
- Existing `DialectExtension` subclasses will need a type ID to be
registered for each subclass. More details on how to register a type ID
can be found here:
https://github.com/llvm/llvm-project/blob/8b68e06731e0033ed3f8d6fe6292ae671611cfa1/mlir/include/mlir/Support/TypeID.h#L30
- Existing uses of the `std::function` overload of `addExtension` will
need to be refactored into dedicated `DialectExtension` classes with
associated type IDs. The attached `std::function` can either be inlined
into or called directly from `DialectExtension::apply`.
---------
Co-authored-by: Mehdi Amini <joker.eph@gmail.com>
show more ...
|
#
d0e6fd99 |
| 05-Sep-2023 |
Fabian Mora <fmora.dev@gmail.com> |
[mlir] Extend the promise interface mechanism
This patch pairs a promised interface with the object (Op/Attr/Type/Dialect) requesting the promise, ie: ``` declarePromisedInterface<MyAttr, MyInterfac
[mlir] Extend the promise interface mechanism
This patch pairs a promised interface with the object (Op/Attr/Type/Dialect) requesting the promise, ie: ``` declarePromisedInterface<MyAttr, MyInterface>(); ``` Allowing to make fine grained promises. It also adds a mechanism to query if `Op/Attr/Type` has an specific promise returning true if the promise is there or if an implementation has been added. Finally it adds a couple of `Attr|TypeConstraints` that can be used in ODS to query if the promise or an implementation is there.
This patch tries to solve 2 issues: 1. Different entities cannot use the same promise. ``` declarePromisedInterface<MyInterface>(); // Resolves a promise. MyAttr1::attachInterface<MyInterface>(ctx); // Doesn't resolves a promise, as the previous attachment removed the promise. MyAttr2::attachInterface<MyInterface>(ctx); ``` 2. Is not possible to query if a promise has been declared.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D158464
show more ...
|
#
012b148d |
| 26-Aug-2023 |
Matthias Springer <me@m-sp.org> |
[mlir] Fix crash when adding nested dialect extensions
A dialect extension can add additional dialect extensions in its `apply` function. This used to crash when the vector of `extensions` was inter
[mlir] Fix crash when adding nested dialect extensions
A dialect extension can add additional dialect extensions in its `apply` function. This used to crash when the vector of `extensions` was internally reallocated while it is being iterated over.
Differential Revision: https://reviews.llvm.org/D158838
show more ...
|
#
4529797a |
| 05-Aug-2023 |
Mehdi Amini <joker.eph@gmail.com> |
Add a generic "convert-to-llvm" pass delegating to an interface
The multiple -convert-XXX-to-llvm passes are really nice testing tools for individual dialects, but the expectation is that a proper c
Add a generic "convert-to-llvm" pass delegating to an interface
The multiple -convert-XXX-to-llvm passes are really nice testing tools for individual dialects, but the expectation is that a proper conversion should assemble the conversion patterns using `populateXXXToLLVMConversionPatterns() APIs. However most customers just chain the conversion passes by convenience.
This pass makes it composable more transparently to assemble the required patterns for conversion to LLVM dialect by using an interface. The Pass will scan the input and collect all the dialect present, and for those who implement the `ConvertToLLVMPatternInterface` it will use it to populate the conversion pattern, and possible the conversion target.
Since these conversions can involve intermediate dialects, or target other dialects than LLVM (for example AVX or NVVM), this pass can't statically declare the required `getDependentDialects()` before the pass pipeline begins. This is worked around by using an extension in the dialectRegistry that will be invoked for every new loaded dialects in the context. This allows to lookup the interface ahead of time and use it to query the dependent dialects.
Differential Revision: https://reviews.llvm.org/D157183
show more ...
|
#
91ae1f5d |
| 24-Jun-2023 |
Mehdi Amini <joker.eph@gmail.com> |
Improve fatal error message when handling promised interfaces
When initializing DialectInterfaceCollection, we wouldn't have the missing interface name in the error.
Differential Revision: https://
Improve fatal error message when handling promised interfaces
When initializing DialectInterfaceCollection, we wouldn't have the missing interface name in the error.
Differential Revision: https://reviews.llvm.org/D153676
show more ...
|
#
a5ef51d7 |
| 22-Feb-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir] Add support for "promised" interfaces
Promised interfaces allow for a dialect to "promise" the implementation of an interface, i.e. declare that it supports an interface, but have the interfa
[mlir] Add support for "promised" interfaces
Promised interfaces allow for a dialect to "promise" the implementation of an interface, i.e. declare that it supports an interface, but have the interface defined in an extension in a library separate from the dialect itself. A promised interface is powerful in that it alerts the user when the interface is attempted to be used (e.g. via cast/dyn_cast/etc.) and the implementation has not yet been provided. This makes the system much more robust against misconfiguration, and ensures that we do not lose the benefit we currently have of defining the interface in the dialect library.
Differential Revision: https://reviews.llvm.org/D120368
show more ...
|
#
22426110 |
| 14-Dec-2022 |
Ramkumar Ramachandra <r@artagnon.com> |
mlir/tblgen: use std::optional in generation
This is part of an effort to migrate from llvm::Optional to std::optional. This patch changes the way mlir-tblgen generates .inc files, and modifies test
mlir/tblgen: use std::optional in generation
This is part of an effort to migrate from llvm::Optional to std::optional. This patch changes the way mlir-tblgen generates .inc files, and modifies tests and documentation appropriately. It is a "no compromises" patch, and doesn't leave the user with an unpleasant mix of llvm::Optional and std::optional.
A non-trivial change has been made to ControlFlowInterfaces to split one constructor into two, relating to a build failure on Windows.
See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Signed-off-by: Ramkumar Ramachandra <r@artagnon.com>
Differential Revision: https://reviews.llvm.org/D138934
show more ...
|
#
1a36588e |
| 04-Dec-2022 |
Kazu Hirata <kazu@google.com> |
[mlir] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of ma
[mlir] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
#
ba8424a2 |
| 19-Sep-2022 |
Mathieu Fehr <mathieu.fehr@gmail.com> |
[mlir] Add Dynamic Dialects
Dynamic dialects are dialects that can be defined at runtime. Dynamic dialects are extensible by new operations, types, and attributes at runtime.
Reviewed By: rriddle
[mlir] Add Dynamic Dialects
Dynamic dialects are dialects that can be defined at runtime. Dynamic dialects are extensible by new operations, types, and attributes at runtime.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D125201
show more ...
|
#
02c2ecb9 |
| 23-Aug-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir:Bytecode] Add initial support for dialect defined attribute/type encodings
Dialects can opt-in to providing custom encodings by implementing the `BytecodeDialectInterface`. This interface prov
[mlir:Bytecode] Add initial support for dialect defined attribute/type encodings
Dialects can opt-in to providing custom encodings by implementing the `BytecodeDialectInterface`. This interface provides hooks, namely `readAttribute`/`readType` and `writeAttribute`/`writeType`, that will be used by the bytecode reader and writer. These hooks are provided a reader and writer implementation that can be used to encode various constructs in the underlying bytecode format. A unique feature of this interface is that dialects may choose to only encode a subset of their attributes and types in a custom bytecode format, which can simplify adding new or experimental components that aren't fully baked.
Differential Revision: https://reviews.llvm.org/D132498
show more ...
|
#
0f304ef0 |
| 19-Jan-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir] Add asserts when changing various MLIRContext configurations
This helps to prevent tsan failures when users inadvertantly mutate the context in a non-safe way.
Differential Revision: https:/
[mlir] Add asserts when changing various MLIRContext configurations
This helps to prevent tsan failures when users inadvertantly mutate the context in a non-safe way.
Differential Revision: https://reviews.llvm.org/D112021
show more ...
|
#
77eee579 |
| 22-Feb-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir] Refactor DialectRegistry delayed interface support into a general DialectExtension mechanism
The current dialect registry allows for attaching delayed interfaces, that are added to attrs/dial
[mlir] Refactor DialectRegistry delayed interface support into a general DialectExtension mechanism
The current dialect registry allows for attaching delayed interfaces, that are added to attrs/dialects/ops/etc. when the owning dialect gets loaded. This is clunky for quite a few reasons, e.g. each interface type has a separate tracking structure, and is also quite limiting. This commit refactors this delayed mutation of dialect constructs into a more general DialectExtension mechanism. This mechanism is essentially a registration callback that is invoked when a set of dialects have been loaded. This allows for attaching interfaces directly on the loaded constructs, and also allows for loading new dependent dialects. The latter of which is extremely useful as it will now enable dependent dialects to only apply in the contexts in which they are necessary. For example, a dialect dependency can now be conditional on if a user actually needs the interface that relies on it.
Differential Revision: https://reviews.llvm.org/D120367
show more ...
|
#
1fc096af |
| 02-Jan-2022 |
Mehdi Amini <joker.eph@gmail.com> |
Apply clang-tidy fixes for performance-unnecessary-value-param to MLIR (NFC)
Reviewed By: Mogball
Differential Revision: https://reviews.llvm.org/D116250
|
#
e5639b3f |
| 22-Dec-2021 |
Mehdi Amini <joker.eph@gmail.com> |
Fix more clang-tidy cleanups in mlir/ (NFC)
|
#
be0a7e9f |
| 07-Dec-2021 |
Mehdi Amini <joker.eph@gmail.com> |
Adjust "end namespace" comment in MLIR to match new agree'd coding style
See D115115 and this mailing list discussion: https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html
Differenti
Adjust "end namespace" comment in MLIR to match new agree'd coding style
See D115115 and this mailing list discussion: https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html
Differential Revision: https://reviews.llvm.org/D115309
show more ...
|
#
195730a6 |
| 16-Nov-2021 |
River Riddle <riddleriver@gmail.com> |
[mlir][NFC] Replace references to Identifier with StringAttr
This is part of the replacement of Identifier with StringAttr.
Differential Revision: https://reviews.llvm.org/D113953
|
#
53120631 |
| 24-Sep-2021 |
River Riddle <riddleriver@gmail.com> |
[mlir:OpAsm] Factor out the common bits of (Op/Dialect)Asm(Parser/Printer)
This has a few benefits: * It allows for defining parsers/printer code blocks that can be shared between operations and a
[mlir:OpAsm] Factor out the common bits of (Op/Dialect)Asm(Parser/Printer)
This has a few benefits: * It allows for defining parsers/printer code blocks that can be shared between operations and attribute/types. * It removes the weird duplication of generic parser/printer hooks, which means that newly added hooks only require touching one class.
Differential Revision: https://reviews.llvm.org/D110375
show more ...
|
#
fd87963e |
| 28-Aug-2021 |
Mehdi Amini <joker.eph@gmail.com> |
Change dialect `printOperation()` hook to `getOperationPrinter()`
This makes the hook return a printer if available, instead of using LogicalResult to indicate if a printer was available (and invok
Change dialect `printOperation()` hook to `getOperationPrinter()`
This makes the hook return a printer if available, instead of using LogicalResult to indicate if a printer was available (and invoked). This allows the caller to detect that the dialect has a printer for a given operation without actually invoking the printer. It'll be leveraged in a future revision to move printing the op name itself under control of the ASMPrinter.
Differential Revision: https://reviews.llvm.org/D108803
show more ...
|
#
9b50844f |
| 02-Aug-2021 |
Vladislav Vinogradov <vlad.vinogradov@intel.com> |
[mlir] Fix delayed object interfaces registration
Store both interfaceID and objectID as key for interface registration callback. Otherwise the implementation allows to register only one external mo
[mlir] Fix delayed object interfaces registration
Store both interfaceID and objectID as key for interface registration callback. Otherwise the implementation allows to register only one external model per one object in the single dialect.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D107274
show more ...
|
#
f8479d9d |
| 28-Jul-2021 |
River Riddle <riddleriver@gmail.com> |
[mlir] Set the namespace of the BuiltinDialect to 'builtin'
Historically the builtin dialect has had an empty namespace. This has unfortunately created a very awkward situation, where many utilities
[mlir] Set the namespace of the BuiltinDialect to 'builtin'
Historically the builtin dialect has had an empty namespace. This has unfortunately created a very awkward situation, where many utilities either have to special case the empty namespace, or just don't work at all right now. This revision adds a namespace to the builtin dialect, and starts to cleanup some of the utilities to no longer handle empty namespaces. For now, the assembly form of builtin operations does not require the `builtin.` prefix. (This should likely be re-evaluated though)
Differential Revision: https://reviews.llvm.org/D105149
show more ...
|
#
d7e89121 |
| 16-Jun-2021 |
Alex Zinenko <zinenko@google.com> |
[mlir] Enable delayed registration of attribute/operation/type interfaces
This functionality is similar to delayed registration of dialect interfaces. It allows external interface models to be regis
[mlir] Enable delayed registration of attribute/operation/type interfaces
This functionality is similar to delayed registration of dialect interfaces. It allows external interface models to be registered before the dialect containing the attribute/operation/type interface is loaded, or even before the context is created.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D104397
show more ...
|
#
a0c776fc |
| 23-Mar-2021 |
Mehdi Amini <joker.eph@gmail.com> |
Add a mechanism for Dialects to customize printing/parsing operations when they are unregistered
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D99007
|
#
e6260ad0 |
| 27-Feb-2021 |
River Riddle <riddleriver@gmail.com> |
[mlir] Simplify various pieces of code now that Identifier has access to the Context/Dialect
This also exposed a bug in Dialect loading where it was not correctly identifying identifiers that had th
[mlir] Simplify various pieces of code now that Identifier has access to the Context/Dialect
This also exposed a bug in Dialect loading where it was not correctly identifying identifiers that had the dialect namespace as a prefix.
Differential Revision: https://reviews.llvm.org/D97431
show more ...
|
#
34ea608a |
| 15-Feb-2021 |
Alex Zinenko <zinenko@google.com> |
[mlir] Support repeated delayed registration of dialect interfaces
Dialects themselves do not support repeated addition of interfaces with the same TypeID. However, in case of delayed registration,
[mlir] Support repeated delayed registration of dialect interfaces
Dialects themselves do not support repeated addition of interfaces with the same TypeID. However, in case of delayed registration, the registry may contain such an interface, or have the same interface registered several times due to, e.g., dependencies. Make sure we delayed registration does not attempt to add an interface with the same TypeID more than once.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D96606
show more ...
|