RRiver Riddle[mlir] Refactor SubElementInterface replace support
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir][ods] Remove StructAttr Depends on D127373 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D127375 | 3 年前 | |
[mlir] Refactor SubElementInterface replace support The current support was essentially the amount necessary to support replacing SymbolRefAttrs, but suffers from various deficiencies (both ergonomic and functional): * Replace crashes if unsupported This makes it really hard to use safely, given that you don't know if you are going to crash or not when using it. * Types aren't supported This seems like a simple missed addition when the attribute replacement support was originally added. * The ergonomics are weird It currently uses an index based replacement, which makes the implementations quite clunky. This commit refactors support to be a bit more ergonomic, and also adds support for types in the process. This was also a great oppurtunity to greatly simplify how replacement is done in the symbol table. Fixes #56355 Differential Revision: https://reviews.llvm.org/D130589 | 3 年前 | |
[mlir] Refactor SubElementInterface replace support The current support was essentially the amount necessary to support replacing SymbolRefAttrs, but suffers from various deficiencies (both ergonomic and functional): * Replace crashes if unsupported This makes it really hard to use safely, given that you don't know if you are going to crash or not when using it. * Types aren't supported This seems like a simple missed addition when the attribute replacement support was originally added. * The ergonomics are weird It currently uses an index based replacement, which makes the implementations quite clunky. This commit refactors support to be a bit more ergonomic, and also adds support for types in the process. This was also a great oppurtunity to greatly simplify how replacement is done in the symbol table. Fixes #56355 Differential Revision: https://reviews.llvm.org/D130589 | 3 年前 | |
[mlir] Allow for attaching external resources to .mlir files This commit enables support for providing and processing external resources within MLIR assembly formats. This is a mechanism with which dialects, and external clients, may attach additional information when printing IR without that information being encoded in the IR itself. External resources are not uniqued within the MLIR context, are not attached directly to any operation, and are solely intended to live and be processed outside of the immediate IR. There are many potential uses of this functionality, for example MLIR's pass crash reproducer could utilize this to attach the pass resource executing when a crash occurs. Other types of uses may be embedding large amounts of binary data, such as weights in ML applications, that shouldn't be copied directly into the MLIR context, but need to be kept adjacent to the IR. External resources are encoded using a key-value pair nested within a dictionary anchored by name either on a dialect, or an externally registered entity. The key is an identifier used to disambiguate the data. The value may be stored in various limited forms, but general encodings use a string (human readable) or blob format (binary). Within the textual format, an example may be of the form: `` mlir {-# // The dialect_resources section within the file-level metadata // dictionary is used to contain any dialect resource entries. dialect_resources: { // Here is a dictionary anchored on "foo_dialect", which is a dialect // namespace. foo_dialect: { // some_dialect_resource is a key to be interpreted by the dialect, // and used to initialize/configure/etc. some_dialect_resource: "Some important resource value" } }, // The external_resources section within the file-level metadata // dictionary is used to contain any non-dialect resource entries. external_resources: { // Here is a dictionary anchored on "mlir_reproducer", which is an // external entity representing MLIR's crash reproducer functionality. mlir_reproducer: { // pipeline is an entry that holds a crash reproducer pipeline // resource. pipeline: "func.func(canonicalize,cse)" } } `` Differential Revision: https://reviews.llvm.org/D126446 | 3 年前 | |
[mlir] Add refineReturnTypes to InferTypeOpInterface refineReturnType method shares the same parameters as inferReturnTypes but gets passed in the return types of the op if known that can be used during refinement passes or for more op specific error reporting. Currently the error reporting on failure is generic and doesn't allow for specializing the returned result based on failure, with this change what would previously have been a separate trait with specialized verification can just be handled as part of inferrence rather than duplicated. refineReturnTypes behaves like inferReturnTypes if no result types are fed in, while the current verification is recast as the default implementation for refineReturnTypes with it calling inferReturnTypes (and so the default type verification now goes through refine and allows for more op specific inference mismatch errors). Differential Revision: https://reviews.llvm.org/D129955 | 3 年前 | |
[mlir] Allow for attaching external resources to .mlir files This commit enables support for providing and processing external resources within MLIR assembly formats. This is a mechanism with which dialects, and external clients, may attach additional information when printing IR without that information being encoded in the IR itself. External resources are not uniqued within the MLIR context, are not attached directly to any operation, and are solely intended to live and be processed outside of the immediate IR. There are many potential uses of this functionality, for example MLIR's pass crash reproducer could utilize this to attach the pass resource executing when a crash occurs. Other types of uses may be embedding large amounts of binary data, such as weights in ML applications, that shouldn't be copied directly into the MLIR context, but need to be kept adjacent to the IR. External resources are encoded using a key-value pair nested within a dictionary anchored by name either on a dialect, or an externally registered entity. The key is an identifier used to disambiguate the data. The value may be stored in various limited forms, but general encodings use a string (human readable) or blob format (binary). Within the textual format, an example may be of the form: `` mlir {-# // The dialect_resources section within the file-level metadata // dictionary is used to contain any dialect resource entries. dialect_resources: { // Here is a dictionary anchored on "foo_dialect", which is a dialect // namespace. foo_dialect: { // some_dialect_resource is a key to be interpreted by the dialect, // and used to initialize/configure/etc. some_dialect_resource: "Some important resource value" } }, // The external_resources section within the file-level metadata // dictionary is used to contain any non-dialect resource entries. external_resources: { // Here is a dictionary anchored on "mlir_reproducer", which is an // external entity representing MLIR's crash reproducer functionality. mlir_reproducer: { // pipeline is an entry that holds a crash reproducer pipeline // resource. pipeline: "func.func(canonicalize,cse)" } } `` Differential Revision: https://reviews.llvm.org/D126446 | 3 年前 | |
[mlir] Allow for attaching external resources to .mlir files This commit enables support for providing and processing external resources within MLIR assembly formats. This is a mechanism with which dialects, and external clients, may attach additional information when printing IR without that information being encoded in the IR itself. External resources are not uniqued within the MLIR context, are not attached directly to any operation, and are solely intended to live and be processed outside of the immediate IR. There are many potential uses of this functionality, for example MLIR's pass crash reproducer could utilize this to attach the pass resource executing when a crash occurs. Other types of uses may be embedding large amounts of binary data, such as weights in ML applications, that shouldn't be copied directly into the MLIR context, but need to be kept adjacent to the IR. External resources are encoded using a key-value pair nested within a dictionary anchored by name either on a dialect, or an externally registered entity. The key is an identifier used to disambiguate the data. The value may be stored in various limited forms, but general encodings use a string (human readable) or blob format (binary). Within the textual format, an example may be of the form: `` mlir {-# // The dialect_resources section within the file-level metadata // dictionary is used to contain any dialect resource entries. dialect_resources: { // Here is a dictionary anchored on "foo_dialect", which is a dialect // namespace. foo_dialect: { // some_dialect_resource is a key to be interpreted by the dialect, // and used to initialize/configure/etc. some_dialect_resource: "Some important resource value" } }, // The external_resources section within the file-level metadata // dictionary is used to contain any non-dialect resource entries. external_resources: { // Here is a dictionary anchored on "mlir_reproducer", which is an // external entity representing MLIR's crash reproducer functionality. mlir_reproducer: { // pipeline is an entry that holds a crash reproducer pipeline // resource. pipeline: "func.func(canonicalize,cse)" } } `` Differential Revision: https://reviews.llvm.org/D126446 | 3 年前 | |
[mlir] Introduce support for parametric side-effects The side effect infrastructure is based on the Effect and Resource class templates, instances of instantiations of which are constructed as thread-local singletons. With this scheme, it is impossible to further parameterize either of those, or the EffectInstance class that contains pointers to an Effect and Resource instances. Such a parameterization is necessary to express more detailed side effects, e.g. those of a loop or a function call with affine operations inside where it is possible to precisely specify the slices of accessed buffers. Include an additional Attribute to EffectInstance class for further parameterization. This allows to leverage the dialect-specific registration and uniquing capabilities of the attribute infrastructure without requiring Effect or Resource instantiations to be attached to a dialect themselves. Split out the generic part of the side effect Tablegen classes into a separate file to avoid generating built-in MemoryEffect interfaces when processing any .td file that includes SideEffectInterfaceBase.td. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D91493 | 5 年前 | |
[mlir] Introduce support for parametric side-effects The side effect infrastructure is based on the Effect and Resource class templates, instances of instantiations of which are constructed as thread-local singletons. With this scheme, it is impossible to further parameterize either of those, or the EffectInstance class that contains pointers to an Effect and Resource instances. Such a parameterization is necessary to express more detailed side effects, e.g. those of a loop or a function call with affine operations inside where it is possible to precisely specify the slices of accessed buffers. Include an additional Attribute to EffectInstance class for further parameterization. This allows to leverage the dialect-specific registration and uniquing capabilities of the attribute infrastructure without requiring Effect or Resource instantiations to be attached to a dialect themselves. Split out the generic part of the side effect Tablegen classes into a separate file to avoid generating built-in MemoryEffect interfaces when processing any .td file that includes SideEffectInterfaceBase.td. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D91493 | 5 年前 | |
[MLIR] Move TestDialect to ::test namespace While the changes are extensive, they basically fall into a few categories: 1) Moving the TestDialect itself. 2) Updating C++ code in tablegen to explicitly use ::mlir, since it will be put in a headers that shouldn't expect a 'using'. 3) Updating some generic MLIR Interface definitions to do the same thing. 4) Updating the Tablegen generator in a few places to be explicit about namespaces 5) Doing the same thing for llvm references, since we no longer pick up the definitions from mlir/Support/LLVM.h Differential Revision: https://reviews.llvm.org/D88251 | 4 年前 | |
[mlir] SCCP add missing pessimistic setting When this was updated in D127139 the update in-place case was no longer marked as pessimistic. Add back in. Differential Revision: https://reviews.llvm.org/D130453 | 3 年前 | |
[mlir:MultiOpDriver] Add operands to worklist should be checked Operand's defining op may not be valid for adding to the worklist under stict mode Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D127180 | 3 年前 | |
[mlir:NFC] Remove the forward declaration of FuncOp in the mlir namespace FuncOp has been moved to the func namespace for a little over a month, the using directive can be dropped now. | 4 年前 | |
[mlir] Allows to query traits from types and attributes Types and attributes now have a hasTrait function that allow users to check if a type defines a trait. Also, AbstractType and AbstractAttribute has now a hasTraitFn field to carry the implementation of the hasTrait function of the concrete type or attribute. This patch also adds the remaining functions to access type and attribute traits in TableGen. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D105202 | 4 年前 | |
[mlir][tblgen] Consistently use $_ctxt instead of $_ctx With the exceptions of AttrOrTypeParameter and DerivedAttr, all of MLIR consistently uses $_ctxt as the substitute variable for the MLIRContext in TableGen C++ code. Usually this does not matter unless one where to reuse some code in multiple fields but it is still needlessly inconsistent and prone to error. This patch fixes that by consistently using _$ctxt everywhere. Differential Revision: https://reviews.llvm.org/D129153 | 3 年前 | |
[mlir:LSP] Add support for code completing attributes and types This required changing a bit of how attributes/types are parsed. A new KeywordSwitch class was added to AsmParser that provides a StringSwitch like API for parsing keywords with a set of potential matches. It intends to both provide a cleaner API, and enable injection for code completion. This required changing the API of generated(Attr|Type)Parser to handle the parsing of the keyword, instead of having the user do it. Most upstream dialects use the autogenerated handling and didn't require a direct update. Differential Revision: https://reviews.llvm.org/D129267 | 3 年前 | |
[mlir] Refactor SubElementInterface replace support The current support was essentially the amount necessary to support replacing SymbolRefAttrs, but suffers from various deficiencies (both ergonomic and functional): * Replace crashes if unsupported This makes it really hard to use safely, given that you don't know if you are going to crash or not when using it. * Types aren't supported This seems like a simple missed addition when the attribute replacement support was originally added. * The ergonomics are weird It currently uses an index based replacement, which makes the implementations quite clunky. This commit refactors support to be a bit more ergonomic, and also adds support for types in the process. This was also a great oppurtunity to greatly simplify how replacement is done in the symbol table. Fixes #56355 Differential Revision: https://reviews.llvm.org/D130589 | 3 年前 | |
[MLIR][NFC] Move TestDialect -> Dialect/Test Move test/lib/TestDialect to test/lib/Dialect/Test - makes the dir structure more uniform. Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Differential Revision: https://reviews.llvm.org/D76677 | 6 年前 |