[mlir] Refactor SubElementInterface replace support

The current support was essentially the amount necessary
to support replacing SymbolRefAttrs, but suffers from various
deficiencies (both ergonomi

[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

show more ...

[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

[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

show more ...

Fix printing for ArrayRef attributes/types in declarative assembly format

These were abbreviated when parsing, but not when printing.

Reviewed By: Mogball, rriddle

Differential Revision: https://r

Fix printing for ArrayRef attributes/types in declarative assembly format

These were abbreviated when parsing, but not when printing.

Reviewed By: Mogball, rriddle

Differential Revision: https://reviews.llvm.org/D128720

show more ...

[mlir][ods] Ignore AttributeSelfTypeParameter in assembly formats

The attribute self type parameter is currently treated like any other attribute parameter in the assembly format. The self type para

[mlir][ods] Ignore AttributeSelfTypeParameter in assembly formats

The attribute self type parameter is currently treated like any other attribute parameter in the assembly format. The self type parameter should be handled by the operation parser and printer and play no role in the generated parsers and printers of attributes.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D125724

show more ...

[mlir] Add extensible dialects

Depends on D104534
Add support for extensible dialects, which are dialects that can be
extended at runtime with new operations and types.

These operations and types c

[mlir] Add extensible dialects

Depends on D104534
Add support for extensible dialects, which are dialects that can be
extended at runtime with new operations and types.

These operations and types cannot at the moment implement traits
or interfaces.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D104554

show more ...

Revert "[mlir] Add extensible dialects"

This reverts commit dbe9f0914fcfd8444fd9656821af0f1a34a27e7a.

The flang-x86_64-windows buildbot has been failing since this has been merged:
* https://lab.ll

Revert "[mlir] Add extensible dialects"

This reverts commit dbe9f0914fcfd8444fd9656821af0f1a34a27e7a.

The flang-x86_64-windows buildbot has been failing since this has been merged:
* https://lab.llvm.org/buildbot/#/builders/172/builds/9124
Similar failure was reported by the pre-commit CI.

show more ...

[mlir] Add extensible dialects

Add support for extensible dialects, which are dialects that can be
extended at runtime with new operations and types.

These operations and types cannot at the moment

[mlir] Add extensible dialects

Add support for extensible dialects, which are dialects that can be
extended at runtime with new operations and types.

These operations and types cannot at the moment implement traits
or interfaces.

Differential Revision: https://reviews.llvm.org/D104554

show more ...

Revert "Define a `cppAccessorType` to const-ref in APFloatParameter and update ODS emitter to use it for verifier signatures"

This reverts commit 89af17c0c74eb9d8d11870f6510e475eff74eef4.

This brok

Revert "Define a `cppAccessorType` to const-ref in APFloatParameter and update ODS emitter to use it for verifier signatures"

This reverts commit 89af17c0c74eb9d8d11870f6510e475eff74eef4.

This broke the gcc5 build.

show more ...

Define a `cppAccessorType` to const-ref in APFloatParameter and update ODS emitter to use it for verifier signatures

This reduce an unnecessary amount of copy of non-trivial objects, like
APFloat.

Define a `cppAccessorType` to const-ref in APFloatParameter and update ODS emitter to use it for verifier signatures

This reduce an unnecessary amount of copy of non-trivial objects, like
APFloat.

Reviewed By: rriddle, jpienaar

Differential Revision: https://reviews.llvm.org/D116505

show more ...

Use base class AsmParser/AsmPrinter in Types and Attribute print/parse method (NFC)

This decouples the printing/parsing from the "context" in which the parsing occurs.
This will allow to invoke thes

Use base class AsmParser/AsmPrinter in Types and Attribute print/parse method (NFC)

This decouples the printing/parsing from the "context" in which the parsing occurs.
This will allow to invoke these methods directly using an OpAsmParser/OpAsmPrinter.

Differential Revision: https://reviews.llvm.org/D113637

show more ...

Change the contract with the type/attribute parsing to let the dispatch handle the mnemonic

This breaking change requires to remove printing the mnemonic in the print()
method on Type/Attribute clas

Change the contract with the type/attribute parsing to let the dispatch handle the mnemonic

This breaking change requires to remove printing the mnemonic in the print()
method on Type/Attribute classes.
This makes it consistent with the parsing code which alread handles the
mnemonic outside of the parsing method.

This likely won't break the build for anyone, but tests will start
failing for dialects downstream. The fix is trivial and look like
going from:

void emitc::OpaqueType::print(DialectAsmPrinter &printer) const {
printer << "opaque<\"";

to:

void emitc::OpaqueAttr::print(DialectAsmPrinter &printer) const {
printer << "<\"";

Reviewed By: rriddle, aartbik

Differential Revision: https://reviews.llvm.org/D113334

show more ...

Emit the boilerplate for Attribute printer/parser dialect dispatching from ODS

Add a new `useDefaultAttributePrinterParser` boolean settings on the dialect
(default to false for now) that emits the

Emit the boilerplate for Attribute printer/parser dialect dispatching from ODS

Add a new `useDefaultAttributePrinterParser` boolean settings on the dialect
(default to false for now) that emits the boilerplate to dispatch attribute
parsing/printing to the auto-generated method.
We will likely turn this on by default in the future.

Differential Revision: https://reviews.llvm.org/D113329

show more ...

[MLIR] Attribute and type formats in ODS

Declarative attribute and type formats with assembly formats. Define an
`assemblyFormat` field in attribute and type defs with a `mnemonic` to
generate a par

[MLIR] Attribute and type formats in ODS

Declarative attribute and type formats with assembly formats. Define an
`assemblyFormat` field in attribute and type defs with a `mnemonic` to
generate a parser and printer.

```tablegen
def MyAttr : AttrDef<MyDialect, "MyAttr"> {
let parameters = (ins "int64_t":$count, "AffineMap":$map);
let mnemonic = "my_attr";
let assemblyFormat = "`<` $count `,` $map `>`";
}
```

Use `struct` to define a comma-separated list of key-value pairs:

```tablegen
def MyType : TypeDef<MyDialect, "MyType"> {
let parameters = (ins "int":$one, "int":$two, "int":$three);
let mnemonic = "my_attr";
let assemblyFormat = "`<` $three `:` struct($one, $two) `>`";
}
```

Use `struct(*)` to capture all parameters.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D111594

show more ...

[mlir] Implement replacement of SymbolRefAttrs in Dialect attributes using SubElementAttr interface

This patch extends the SubElementAttr interface to allow replacing a contained sub attribute. The

[mlir] Implement replacement of SymbolRefAttrs in Dialect attributes using SubElementAttr interface

This patch extends the SubElementAttr interface to allow replacing a contained sub attribute. The attribute that should be replaced is identified by an index which denotes the n-th element returned by the accompanying walkImmediateSubElements method.

Using this addition the patch implements replacing SymbolRefAttrs contained within any dialect attributes.

Differential Revision: https://reviews.llvm.org/D111357

show more ...

[ODS/AsmParser] Don't pass MLIRContext with DialectAsmParser.

The former is redundant because the later carries it as part of
its builder. Add a getContext() helper method to DialectAsmParser
to ma

[ODS/AsmParser] Don't pass MLIRContext with DialectAsmParser.

The former is redundant because the later carries it as part of
its builder. Add a getContext() helper method to DialectAsmParser
to make this more convenient, and stop passing the context around
explicitly. This simplifies ODS generated parser hooks for attrs
and types.

This resolves PR51985

Recommit 4b32f8bac4 after fixing a dependency.

Differential Revision: https://reviews.llvm.org/D110796

show more ...

Revert "[ODS/AsmParser] Don't pass MLIRContext with DialectAsmParser."

This reverts commit 4b32f8bac40dcd1535bfe95757c3de0911bf6d1a.

Seems like the build is broken with -DDBUILD_SHARED_LIBS=ON

[ODS/AsmParser] Don't pass MLIRContext with DialectAsmParser.

The former is redundant because the later carries it as part of
its builder. Add a getContext() helper method to DialectAsmParser
to ma

[ODS/AsmParser] Don't pass MLIRContext with DialectAsmParser.

The former is redundant because the later carries it as part of
its builder. Add a getContext() helper method to DialectAsmParser
to make this more convenient, and stop passing the context around
explicitly. This simplifies ODS generated parser hooks for attrs
and types.

This resolves PR51985

Differential Revision: https://reviews.llvm.org/D110796

show more ...

[mlir] Refactor ElementsAttr into an AttrInterface

This revision refactors ElementsAttr into an Attribute Interface.
This enables a common interface with which to interact with
element attributes, w

[mlir] Refactor ElementsAttr into an AttrInterface

This revision refactors ElementsAttr into an Attribute Interface.
This enables a common interface with which to interact with
element attributes, without needing to modify the builtin
dialect. It also removes a majority (if not all?) of the need for
the current OpaqueElementsAttr, which was originally intended as
a way to opaquely represent data that was not representable by
the other builtin constructs.

The new ElementsAttr interface not only allows for users to
natively represent their data in the way that best suits them,
it also allows for efficient opaque access and iteration of the
underlying data. Attributes using the ElementsAttr interface
can directly expose support for interacting with the held
elements using any C++ data type they claim to support. For
example, DenseIntOrFpElementsAttr supports iteration using
various native C++ integer/float data types, as well as
APInt/APFloat, and more. ElementsAttr instances that refer to
DenseIntOrFpElementsAttr can use all of these data types for
iteration:

```c++
DenseIntOrFpElementsAttr intElementsAttr = ...;

ElementsAttr attr = intElementsAttr;
for (uint64_t value : attr.getValues<uint64_t>())
...;
for (APInt value : attr.getValues<APInt>())
...;
for (IntegerAttr value : attr.getValues<IntegerAttr>())
...;
```

ElementsAttr also supports failable range/iterator access,
allowing for selective code paths depending on data type
support:

```c++
ElementsAttr attr = ...;
if (auto range = attr.tryGetValues<uint64_t>()) {
for (uint64_t value : *range)
...;
}
```

Differential Revision: https://reviews.llvm.org/D109190

show more ...

[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 explicit

[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

show more ...

[mlir] separable registration of attribute and type interfaces

It may be desirable to provide an interface implementation for an attribute or
a type without modifying the definition of said attribut

[mlir] separable registration of attribute and type interfaces

It may be desirable to provide an interface implementation for an attribute or
a type without modifying the definition of said attribute or type. Notably,
this allows to implement interfaces for attributes and types outside of the
dialect that defines them and, in particular, provide interfaces for built-in
types. Provide the mechanism to do so.

Currently, separable registration requires the attribute or type to have been
registered with the context, i.e. for the dialect containing the attribute or
type to be loaded. This can be relaxed in the future using a mechanism similar
to delayed dialect interface registration.

See https://llvm.discourse.group/t/rfc-separable-attribute-type-interfaces/3637

Depends On D104233

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D104234

show more ...

[mlir][StorageUniquer] Properly call the destructor on non-trivially destructible storage instances

This allows for storage instances to store data that isn't uniqued in the context, or contain othe

[mlir][StorageUniquer] Properly call the destructor on non-trivially destructible storage instances

This allows for storage instances to store data that isn't uniqued in the context, or contain otherwise non-trivial logic, in the rare situations that they occur. Storage instances with trivial destructors will still have their destructor skipped. A consequence of this is that the storage instance definition must be visible from the place that registers the type.

Differential Revision: https://reviews.llvm.org/D98311

show more ...

Switch generatedTypeParser/generatedAttributeParser to return an OptionalParseResult

This allows the caller to distinguish between a parse error or an
unmatched keyword. It fixes the redundant error

Switch generatedTypeParser/generatedAttributeParser to return an OptionalParseResult

This allows the caller to distinguish between a parse error or an
unmatched keyword. It fixes the redundant error that was emitted by the
caller when the generated parser would fail.

Differential Revision: https://reviews.llvm.org/D98162

show more ...

[mlir][AttrDefGen] Add support for specifying the value type of an attribute

The value type of the attribute can be specified by either overriding the typeBuilder field on the AttrDef, or by providi

[mlir][AttrDefGen] Add support for specifying the value type of an attribute

The value type of the attribute can be specified by either overriding the typeBuilder field on the AttrDef, or by providing a parameter of type `AttributeSelfTypeParameter`. This removes the need to define custom storage class constructors for attributes that have a value type other than NoneType.

Differential Revision: https://reviews.llvm.org/D97590

show more ...

[mlir] Add support for generating Attribute classes for ODS

The support for attributes closely maps that of Types (basically 1-1) given that Attributes are defined in exactly the same way as Types.

[mlir] Add support for generating Attribute classes for ODS

The support for attributes closely maps that of Types (basically 1-1) given that Attributes are defined in exactly the same way as Types. All of the current ODS TypeDef classes get an Attr equivalent. The generation of the attribute classes themselves share the same generator as types.

Differential Revision: https://reviews.llvm.org/D97589

show more ...