[mlir] (NFC) run clang-format on all files

[mlir] Allow empty lists for DenseArrayAttr.

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

Read/write external resource alignment tag in little-endian

https://reviews.llvm.org/D126446 added support for encoding
binary blobs in MLIR assembly. To enable cross-architecture
compatibility, th

Read/write external resource alignment tag in little-endian

https://reviews.llvm.org/D126446 added support for encoding
binary blobs in MLIR assembly. To enable cross-architecture
compatibility, these need to be encoded in little-endian format.

This patch is a first step in that direction by reading and
writing the alignment tag that those blobs are prefixed by
in little-endian format. This fixes assertion failures in
several test cases on big-endian platforms.

The actual content of the blob is not yet handled here.

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

show more ...

[mlir:Parser] Don't use strings for the "ugly" form of Attribute/Type syntax

This commit refactors the syntax of "ugly" attribute/type formats to not use
strings for wrapping. This means that moving

[mlir:Parser] Don't use strings for the "ugly" form of Attribute/Type syntax

This commit refactors the syntax of "ugly" attribute/type formats to not use
strings for wrapping. This means that moving forward attirbutes and type formats
will always need to be in some recognizable form, i.e. if they use incompatible
characters they will need to manually wrap those in a string, the framework will
no longer do it automatically.

This has the benefit of greatly simplifying how parsing attributes/types work, given
that we currently rely on some extremely complicated nested parser logic which is
quite problematic for a myriad of reasons; unecessary complexity(we create a nested
source manager/lexer/etc.), diagnostic locations can be off/wrong given string escaping,
etc.

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

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 ...

Introduce a new Dense Array attribute

This attribute is similar to DenseElementsAttr but does not support
splat. As such it has a much simpler API and does not need any smart
iterator: it exposes di

Introduce a new Dense Array attribute

This attribute is similar to DenseElementsAttr but does not support
splat. As such it has a much simpler API and does not need any smart
iterator: it exposes direct ArrayRef access.

A new syntax is introduced so that the generic printing/parsing looks
like:

[:i64 1, -2, 3]

This attribute beings like an ArrayAttr but has a `:` token after the
opening square brace to introduce the element type (supported are I8,
I16, I32, I64, F32, F64) and the comma separated list for the data.

This is particularly convenient for attributes intended to be small,
like those referring to shapes.
For example a `transpose` operation with a `dims` attribute could be
defined as such:

let arguments = (ins AnyTensor:$input, DenseI64ArrayAttr:$dims);
let assemblyFormat = "$input `dims` `=` $dims attr-dict : type($input)";

And printed this way (the element type is elided in this case):

transpose %input dims = [0, 2, 1] : tensor<2x3x4xf32>

The C++ API for dims would just directly return an ArrayRef<int64>

RFC: https://discourse.llvm.org/t/rfc-introduce-a-new-dense-array-attribute/63279

Recommit with a custom DenseArrayBaseAttrStorage class to ensure
over-alignment of the storage to the largest type.

Reviewed By: rriddle

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

show more ...

Revert "Introduce a new Dense Array attribute"

This reverts commit 508eb41d82ca956c30950d9a16b522a29aeeb333.

UBSAN indicates some pointer mis-alignment I need to investigate

Introduce a new Dense Array attribute

This attribute is similar to DenseElementsAttr but does not support
splat. As such it has a much simpler API and does not need any smart
iterator: it exposes di

Introduce a new Dense Array attribute

This attribute is similar to DenseElementsAttr but does not support
splat. As such it has a much simpler API and does not need any smart
iterator: it exposes direct ArrayRef access.

A new syntax is introduced so that the generic printing/parsing looks
like:

[:i64 1, -2, 3]

This attribute beings like an ArrayAttr but has a `:` token after the
opening square brace to introduce the element type (supported are I8,
I16, I32, I64, F32, F64) and the comma separated list for the data.

This is particularly convenient for attributes intended to be small,
like those referring to shapes.
For example a `transpose` operation with a `dims` attribute could be
defined as such:

let arguments = (ins AnyTensor:$input, DenseI64ArrayAttr:$dims);
let assemblyFormat = "$input `dims` `=` $dims attr-dict : type($input)";

And printed this way (the element type is elided in this case):

transpose %input dims = [0, 2, 1] : tensor<2x3x4xf32>

The C++ API for dims would just directly return an ArrayRef<int64>

RFC: https://discourse.llvm.org/t/rfc-introduce-a-new-dense-array-attribute/63279

Reviewed By: rriddle

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

show more ...

Don't use Optional::hasValue (NFC)

[mlir] Don't use Optional::hasValue (NFC)

[mlir:Printer][NFC] Add utility methods for printing escaped/hex strings

This simplifies quite a few cases where we manually duplicate the
escaping logic.

[mlir] do not elide dialect prefix for ops with dots in the name

For the hypothetical "a.b.c" op printed within a region that declares "a" as
the default dialect, MLIR would currently elide the "a."

[mlir] do not elide dialect prefix for ops with dots in the name

For the hypothetical "a.b.c" op printed within a region that declares "a" as
the default dialect, MLIR would currently elide the "a." prefix and only print
"b.c". However, this becomes ambiguous while parsing as "b.c" may be exist as
the "c" op in the "b" dialect. If it does not, the parsing currently fails. Do
not elide the default dialect if the op name contains further dots to avoid the
ambiguity.

See https://discourse.llvm.org/t/dropping-dialect-prefix-for-ops-with-multiple-dots-in-the-name/62562

Reviewed By: rriddle

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

show more ...

[mlir] Remove the `type` keyword from type alias definitions

This was carry over from LLVM IR where the alias definition can
be ambiguous, but MLIR type aliases have no such problems.
Having the `ty

[mlir] Remove the `type` keyword from type alias definitions

This was carry over from LLVM IR where the alias definition can
be ambiguous, but MLIR type aliases have no such problems.
Having the `type` keyword is superfluous and doesn't add anything.
This commit drops it, which also nicely aligns with the syntax for
attribute aliases (which doesn't have a keyword).

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

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] Print some message for op-printing verification

Before dump, Insetad of switching to generic form silently after
verification failure. Print some debug logs to help identify why an op
may be

[mlir] Print some message for op-printing verification

Before dump, Insetad of switching to generic form silently after
verification failure. Print some debug logs to help identify why an op
may be printed in a different way.

Reviewed By: rriddle

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

show more ...

[MLIR] Add option to print users of an operation as comment in the printer

This allows printing the users of an operation as proposed in the git issue #53286.
To be able to refer to operations with

[MLIR] Add option to print users of an operation as comment in the printer

This allows printing the users of an operation as proposed in the git issue #53286.
To be able to refer to operations with no result, these operations are assigned an
ID in SSANameState.

Reviewed By: mehdi_amini

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

show more ...

[mlir] Fix dumping invalid ops

This patch fixes the crash when printing some ops (like affine.for and
scf.for) when they are dumped in invalid state, e.g. during pattern
application. Now the AsmStat

[mlir] Fix dumping invalid ops

This patch fixes the crash when printing some ops (like affine.for and
scf.for) when they are dumped in invalid state, e.g. during pattern
application. Now the AsmState constructor verifies the operation
first and switches to generic operation printing when the verification
fails. Also operations are now printed in generic form when emitting
diagnostics and the severity level is Error.

Reviewed By: rriddle, mehdi_amini

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

show more ...

[mlir] Expose printer flags in AsmState

This change exposes printer flags in AsmState and AsmStateImpl. All functions
receiving AsmState as a parameter now use the flags from the AsmState instead of

[mlir] Expose printer flags in AsmState

This change exposes printer flags in AsmState and AsmStateImpl. All functions
receiving AsmState as a parameter now use the flags from the AsmState instead of
taking an additional OpPrintingFlags parameter.

Reviewed By: rriddle

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

show more ...

Add a new interface method `getAsmBlockName()` on OpAsmOpInterface to control block names

This allows operations to control the block ids used by the printer in nested regions.

Reviewed By: Mogball

Add a new interface method `getAsmBlockName()` on OpAsmOpInterface to control block names

This allows operations to control the block ids used by the printer in nested regions.

Reviewed By: Mogball

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

show more ...

Delete dead code

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

[MLIR] Improve doc for -mlir-print-local-scope and unhide

This is a pretty important debugging option to stay hidden. Also,
improve its cmd-line description; the current description gives no hint
th

[MLIR] Improve doc for -mlir-print-local-scope and unhide

This is a pretty important debugging option to stay hidden. Also,
improve its cmd-line description; the current description gives no hint
that this is the one to use to have locations printed inline.
Out-of-line locations are also unproductive to work with in many cases
where the locations are actually compact, which is also why this option
should be more visible. This revision doesn't change the default on it
though.

Reviewed By: rriddle, jpienaar

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

show more ...

Remove obsolete `getAsmResultNames` from OpAsmDialectInterface

This is superseded by the same method on OpAsmOpInterface, which is
available on the Dialect through the Fallback mechanism,

Reviewed

Remove obsolete `getAsmResultNames` from OpAsmDialectInterface

This is superseded by the same method on OpAsmOpInterface, which is
available on the Dialect through the Fallback mechanism,

Reviewed By: rriddle

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

show more ...

[mlir] Don't print `// no predecessors` on entry blocks

Entry blocks can never have predecessors, so this is unnecessary.

Fixes #53287

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

Change elided large constant syntax to make it more explicit

When the printer is requested to elide large constant, we emit an opaque
attribute instead. This patch fills the dialect name with
"elide

Change elided large constant syntax to make it more explicit

When the printer is requested to elide large constant, we emit an opaque
attribute instead. This patch fills the dialect name with
"elided_large_const" instead of "_" to remove some user confusion when
they later try to consume it.

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

show more ...

[mlir] Drop the leading space when printing regions

The leading space that is always printed at the beginning of regions is not consistent with other parts of the printing API. Moreover, this leadin

[mlir] Drop the leading space when printing regions

The leading space that is always printed at the beginning of regions is not consistent with other parts of the printing API. Moreover, this leading space can lead to undesirable assembly formats:

```
attr-dict-with-keyword $region
```

Prints as:

```
// Two spaces between `}` and `{`
attributes {foo} { ... }
```

Moreover, the leading space results in the odd generic op format:

```
"test.op"() ( {...}) : () -> ()
```

Reviewed By: rriddle, mehdi_amini

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

show more ...