| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Examle:
substitute
mesh.cluster @mesh0(rank = 2, dim_sizes = [0, 4])
with
mesh.cluster @mesh0(rank = 2, dim_sizes = ?x4)
Same as tensor/memref shapes. The only difference is for 0-rank shapes.
With tensors you would have something like `tensor<f32>`. Here to avoid
matching an empty string a 0-rank shape is denoted by `[]`.
|
|
When cloning an operation with a region, the builder was currently
notifying about the insertion of the cloned operations inside the region
before the cloned operation itself.
When using cloning inside rewrite pass, this could cause issues if a
pattern is expected to be applied on a cloned parent operation before
trying to apply patterns on the cloned operations it contains (the
patterns are attempted in order of notifications for the cloned
operations).
|
|
`bufferization.materialize_in_destination` should be used instead. Both
ops bufferize to a memcpy. This change also conceptually cleans up the
memref dialect a bit: the memref dialect no longer contains ops that
operate on tensor values.
|
|
Fixes #61871 and fixes #60581.
This PR fixes two small things. First and foremost, it throws a clear
error in the `-test-elements-attr-interface` when those tests are called
on elements which are not an integer. I've looked through the
introduction of the attribute interface
(https://reviews.llvm.org/D109190) and later commits and see no evidence
that the interface (`attr.tryGetValues<T>()`) is expected to handle
mismatching types.
For example, the case which is given in #61871 is:
```mlir
arith.constant sparse<[[0, 0, 5]], -2.0> : vector<1x1x10xf16>
```
So, a sparse vector containing `f16` elements. This will crash at
various locations when called in the test because the test introduces
integer types (`int64_t`, `uint64_t`, `APInt`, `IntegerAttr`), but as I
said in the previous paragraph: I see no reason to believe that the
implementation of the interface is wrong here. The interface just
assumes that clients don't do things like `attr.tryGetValues<APInt>()`
on a floating point `attr`.
Also I've added a test for the implementation of this interface by the
`sparse` dialect. There were no problems there. Still, probably good to
increase code coverage on that one.
|
|
Table of Operands for operations like:
https://mlir.llvm.org/docs/Dialects/MemRef/#operands-6
Don't distinguish variadic ODS operands from others right now.
After this change, it'll print:
| Operand | Description |
| dynamicSizes | Variadic of index |
instead of:
| Operand | Description |
| dynamicSizes | index |
|
|
Previously the error reported location would not be where expected. E.g., it would fail in the existing test if it wasn't the last in the file.
|
|
TensorType encoding field
Fixes #67525
|
|
Those fixes were taken from https://reviews.llvm.org/D137338
|
|
The alias initializer keeps a list of child indices around. When an alias is then marked as non-deferrable, all children are also marked non-deferrable.
This is currently done naively which leads to an infinite recursion if using mutable types or attributes containing a cycle.
This patch fixes this by adding an early return if the alias is already marked non-deferrable. Since this function is the only way to mark an alias as non-deferrable, it is guaranteed that if it is marked non-deferrable, all its children are as well, and it is not required to walk all the children.
This incidentally makes the non-deferrable marking also `O(n)` instead of `O(n^2)` (although not performance sensitive obviously).
Differential Revision: https://reviews.llvm.org/D158932
|
|
In https://reviews.llvm.org/D157928 ellison of printing resources was added.
In the refactor, the proper printing of escape characters was mistakenly removed.
This patch adds it back in and adds a small unit test.
Reviewed By: Mogball
Differential Revision: https://reviews.llvm.org/D158700
|
|
Often times, large weights for ML models will be stored as resources in MLIR. It is sometimes advantageous to control whether to print these resources for debugging purposes. For example, some models contain very big weights with millions of characters in printed size, which may slow down whatever text editor you are using.
This diff adds a flag which allows users to disable printing resources in these scenarios.
Reviewed By: Mogball
Differential Revision: https://reviews.llvm.org/D157928
|
|
The verifier incorrectly passed the region number of the predecessor region instead of the successor region to `getSuccessorOperands`. This went unnoticed since all upstream `RegionBranchTerminatorOpInterface` implementations did not make use of the `index` parameter.
Adding an assert to e.g. `scf.condition` to make sure the index is valid or adding a region terminator that passes different operands to different successors immediately causes the verifier to fail as it suddenly gets incorrect types.
This patch fixes the implementation to correctly pass the successor region index.
Differential Revision: https://reviews.llvm.org/D157507
|
|
`operandSegmentSizes`
This renaming started with the native ODS support for properties, this is completing it.
A mass automated textual rename seems safe for most codebases.
Drop also the ods prefix to keep the accessors the same as they were before
this change:
properties.odsOperandSegmentSizes
reverts back to:
properties.operandSegementSizes
The ODS prefix was creating divergence between all the places and make it harder to
be consistent.
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D157173
|
|
The operand_segment_sizes and result_segment_sizes Attributes are now inlined
in the operation as native propertie. We continue to support building an
Attribute on the fly for `getAttr("operand_segment_sizes")` and setting the
property from an attribute with `setAttr("operand_segment_sizes", attr)`.
A new bytecode version is introduced to support backward compatibility and
backdeployments.
Differential Revision: https://reviews.llvm.org/D155919
|
|
Properties"
This reverts commit 20b93abca6516bbb23689c3777536fea04e46e14.
One python test is broken, WIP.
|
|
The operand_segment_sizes and result_segment_sizes Attributes are now inlined
in the operation as native propertie. We continue to support building an
Attribute on the fly for `getAttr("operand_segment_sizes")` and setting the
property from an attribute with `setAttr("operand_segment_sizes", attr)`.
A new bytecode version is introduced to support backward compatibility and
backdeployments.
Differential Revision: https://reviews.llvm.org/D155919
|
|
Using properties currently requires at the very least implementing four methods/code snippets:
* `convertToAttribute`
* `convertFromAttribute`
* `writeToMlirBytecode`
* `readFromMlirBytecode`
This makes replacing attributes with properties harder than it has to be: Attributes by default do not require immediately defining custom bytecode encoding.
This patch therefore adds opt-in implementations of `writeToMlirBytecode` and `readFromMlirBytecode` that work with the default implementations of `convertToAttribute` and `convertFromAttribute`. They are provided by `defvar`s in `OpBase.td` and can be used by adding:
```
let writeToMlirBytecode = writeMlirBytecodeWithConvertToAttribute;
let readFromMlirBytecode = readMlirBytecodeUsingConvertFromAttribute;
```
to ones TableGen definition.
While this bytecode encoding is almost certainly not ideal for a given property, it allows more incremental use of properties and getting something sane working before optimizing the bytecode format.
Differential Revision: https://reviews.llvm.org/D155286
|
|
This is essentially a follow up to https://reviews.llvm.org/D155072
This adds support for also passing properties as `ref` parameter to `custom`. This requires the property to have been bound previously and will error otherwise. This makes it possible for an implementation of `custom` to take previously parsed data into account, creating nice context-dependent grammars :-)
Differential Revision: https://reviews.llvm.org/D155297
|
|
It was forgetting commas.
Reviewed By: rriddle, jpienaar
Differential Revision: https://reviews.llvm.org/D155348
|
|
In cases where memory is of less of a concern (e.g. small attributes where all instances have to be distinct by definition), using `DistinctAttr` with a unit attribute is a useful and conscious way of generating deterministic unique IDs.
The syntax as is however, makes them less useful to use, as it 1) always prints `<unit>` at the back and 2) always aliases them leading to not very useful `#distinct = distinct[n]<unit>` lines in the printer output.
This patch fixes that by special casing `UnitAttr` to simply elide the `unit` attribute in the back and not printing it as alias in that case.
Differential Revision: https://reviews.llvm.org/D155162
|
|
Printing and parsing properties of ops is currently only possible through the `prop-dict` attribute. This forces a specific place that the property is printed at and is generally not very flexible.
This patch adds support for passing properties to the `custom` directive, making it possible to incorporate them with more complex syntax. This makes it possible to parse and print them without generic syntax and without the use of `prop-dict`.
Differential Revision: https://reviews.llvm.org/D155072
|
|
A distinct attribute associates a referenced attribute with a unique
identifier. Every call to its create function allocates a new
distinct attribute instance. The address of the attribute instance
temporarily serves as its unique identifier. Similar to the names
of SSA values, the final unique identifiers are generated during
pretty printing.
Examples:
#distinct = distinct[0]<42.0 : f32>
#distinct1 = distinct[1]<42.0 : f32>
#distinct2 = distinct[2]<array<i32: 10, 42>>
This mechanism is meant to generate attributes with a unique
identifier, which can be used to mark groups of operations
that share a common properties such as if they are aliasing.
The design of the distinct attribute ensures minimal memory
footprint per distinct attribute since it only contains a reference
to another attribute. All distinct attributes are stored outside of
the storage uniquer in a thread local store that is part of the
context. It uses one bump pointer allocator per thread to ensure
distinct attributes can be created in-parallel.
Reviewed By: rriddle, Dinistro, zero9178
Differential Revision: https://reviews.llvm.org/D153360
|
|
Fixes buffer overflows which occurred anytime a "test.verifiers" op was used.
Fixes #61378, fixes #61379, fixes #61381.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D154792
|
|
This diff adds support for TF32 as a Builtin floating point type. This
supplements the recent addition of the TF32 semantic to the LLVM APFloat class
by extending usage to MLIR.
https://reviews.llvm.org/D151923
More information on the TF32 type can be found here:
https://blogs.nvidia.com/blog/2020/05/14/tensorfloat-32-precision-format/
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D153705
|
|
This fixes a few custom printers which were printing IR that couldn't be
round-tripped.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D150080
|
|
The greedy pattern rewrite driver removes ops that are "trivially dead". This could include symbols that are still referenced by other ops. Dead symbols should be removed with the `-symbol-dce` pass instead.
This bug was not triggered for `func::FuncOp`, because ops are not considered "trivally dead" if they do not implement the `MemoryEffectOpInterface`, indicating that the op may or may not have side effects. It is, however, triggered for `transform::NamedSequenceOp`, which implements that interface because it is required for all transform dialect ops.
Differential Revision: https://reviews.llvm.org/D152994
|
|
Add an options object to allow control of the slice computation (for
both forward and backward slice). This makes the ABI stable, and also
allows avoiding an assert that makes the slice analysis unusable for
operations with multiple blocks.
Reviewed By: hanchung, nicolasvasilache
Differential Revision: https://reviews.llvm.org/D151520
|
|
Zero ranked tensor (say tensor<i1>) when used for arith.select's condition,
crashes optimizer during bufferization. This patch puts a constraint on
condition to be either scalar or of matching shape as to its result.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D151270
|
|
This is part of an on-going migration to adopt Properties inside MLIR.
Differential Revision: https://reviews.llvm.org/D148297
|
|
This new features enabled to dedicate custom storage inline within operations.
This storage can be used as an alternative to attributes to store data that is
specific to an operation. Attribute can also be stored inside the properties
storage if desired, but any kind of data can be present as well. This offers
a way to store and mutate data without uniquing in the Context like Attribute.
See the OpPropertiesTest.cpp for an example where a struct with a
std::vector<> is attached to an operation and mutated in-place:
struct TestProperties {
int a = -1;
float b = -1.;
std::vector<int64_t> array = {-33};
};
More complex scheme (including reference-counting) are also possible.
The only constraint to enable storing a C++ object as "properties" on an
operation is to implement three functions:
- convert from the candidate object to an Attribute
- convert from the Attribute to the candidate object
- hash the object
Optional the parsing and printing can also be customized with 2 extra
functions.
A new options is introduced to ODS to allow dialects to specify:
let usePropertiesForAttributes = 1;
When set to true, the inherent attributes for all the ops in this dialect
will be using properties instead of being stored alongside discardable
attributes.
The TestDialect showcases this feature.
Another change is that we introduce new APIs on the Operation class
to access separately the inherent attributes from the discardable ones.
We envision deprecating and removing the `getAttr()`, `getAttrsDictionary()`,
and other similar method which don't make the distinction explicit, leading
to an entirely separate namespace for discardable attributes.
Recommit d572cd1b067f after fixing python bindings build.
Differential Revision: https://reviews.llvm.org/D141742
|
|
This reverts commit d572cd1b067f1177a981a4711bf2e501eaa8117b.
Some bots are broken and investigation is needed before relanding.
|
|
This new features enabled to dedicate custom storage inline within operations.
This storage can be used as an alternative to attributes to store data that is
specific to an operation. Attribute can also be stored inside the properties
storage if desired, but any kind of data can be present as well. This offers
a way to store and mutate data without uniquing in the Context like Attribute.
See the OpPropertiesTest.cpp for an example where a struct with a
std::vector<> is attached to an operation and mutated in-place:
struct TestProperties {
int a = -1;
float b = -1.;
std::vector<int64_t> array = {-33};
};
More complex scheme (including reference-counting) are also possible.
The only constraint to enable storing a C++ object as "properties" on an
operation is to implement three functions:
- convert from the candidate object to an Attribute
- convert from the Attribute to the candidate object
- hash the object
Optional the parsing and printing can also be customized with 2 extra
functions.
A new options is introduced to ODS to allow dialects to specify:
let usePropertiesForAttributes = 1;
When set to true, the inherent attributes for all the ops in this dialect
will be using properties instead of being stored alongside discardable
attributes.
The TestDialect showcases this feature.
Another change is that we introduce new APIs on the Operation class
to access separately the inherent attributes from the discardable ones.
We envision deprecating and removing the `getAttr()`, `getAttrsDictionary()`,
and other similar method which don't make the distinction explicit, leading
to an entirely separate namespace for discardable attributes.
Differential Revision: https://reviews.llvm.org/D141742
|
|
This patch introduces support for m_Op with a StringRef argument and m_Attr matchers. These matchers will be very useful for mlir-query that is being developed currently.
Submitting this patch separately to reduce the final patch size and make it easier to upstream mlir-query.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D147262
|
|
The current implementation does not verify the type constraint, meaning that any type that happens to be of the same C++ type would pass the verifier.
E.g. a `TypeAttrOf<I64>` would happily accept a `i32` since both satisfy `isa<IntegerType>()`.
This patch fixes that by adding an optional type predicate parameter to `TypeAttrBase` that the type within `TypeAttr` has to satisfy. `TypeAttrOf` then simply passes the predicate of its type parameter as argument.
Differential Revision: https://reviews.llvm.org/D147778
|
|
is empty
The current behaviour of always writing the unqualified form of an attribute or type is problematic for any type or attribute that might output an empty string, making it impossible to parse and therefore roundtrip. This is commonly the case for any types or attributes with optional parameters. One would have to currently woarkaround the issue by either changing ones syntax to not be completetly empty or by explicitly using `qualified` in ALL ops using that type or attribute.
This patch fixes that issue by simply checking whether anything was written to the output. In the case there wasn't, it simply falls back to using the normal printer with the dialect prefix. This also makes the default of unqualified printing always correct and safe. The implementation could theoretically still be tricked if the user were to print just a space or similar. I'd argue this'd be user error and not worth handling.
Fixes https://github.com/llvm/llvm-project/issues/61701
Differential Revision: https://reviews.llvm.org/D146944
|
|
X. Sun et al. (https://dl.acm.org/doi/10.5555/3454287.3454728) published
a paper showing that an FP format with 4 bits of exponent, 3 bits of
significand and an exponent bias of 11 would work quite well for ML
applications.
Google hardware supports a variant of this format where 0x80 is used to
represent NaN, as in the Float8E4M3FNUZ format. Just like the
Float8E4M3FNUZ format, this format does not support -0 and values which
would map to it will become +0.
This format is proposed for inclusion in OpenXLA's StableHLO dialect: https://github.com/openxla/stablehlo/pull/1308
As part of inclusion in that dialect, APFloat needs to know how to
handle this format.
Differential Revision: https://reviews.llvm.org/D146441
|
|
Blocks are enumerated depth-first, but post-order. I.e., a block is enumerated when its successors have been enumerated. This iteration style is suitable when deleting blocks in a regions: in the absence of cycles, uses are deleted before their definitions.
Differential Revision: https://reviews.llvm.org/D146125
|
|
Fixes #61374
|
|
This iterator is similar to `ForwardIterator` but enumerates blocks according to their successor relationship. As a first use case, this new iterator is utilized in the dialect conversion framework.
Differential Revision: https://reviews.llvm.org/D144888
|
|
This allows users to provide custom `Iterator` templates. A new iterator will be added in a subsequent change.
Also rename `makeRange` to `makeIterable` and add a test case for the reverse iterator.
Differential Revision: https://reviews.llvm.org/D144887
|
|
Mehdi noted in https://reviews.llvm.org/D144391 that given the low cost of keeping the old `fold` method signature working and the difficulty of writing a `FoldAdaptor` oneself, it'd be nice to keep the support for the sake of Ops written manually in C++.
This patch therefore partially reverts the removal of the old `fold` method by still allowing the old signature to be used. The active use of it is still discouraged and ODS will always generate the new method using `FoldAdaptor`s.
I'd also like to note that the previous ought to have broken some manually defined `fold` methods in-tree that are defined here: https://github.com/llvm/llvm-project/blob/23bcd6b86271f1c219a69183a5d90654faca64b8/mlir/include/mlir/Dialect/Affine/IR/AffineOps.h#L245 It seems like these are not part of the regressions tests however...
Differential Revision: https://reviews.llvm.org/D144591
|
|
Float8E5M2FNUZ and Float8E4M3FNUZ have been added to APFloat in D141863.
This change adds these types as MLIR builtin types alongside Float8E5M2
and Float8E4M3FN (added in D133823 and D138075).
Reviewed By: krzysz00
Differential Revision: https://reviews.llvm.org/D143744
|
|
This commit restructures the sub element infrastructure to be a core part
of attributes and types, instead of being relegated to an interface. This
establishes sub element walking/replacement as something "always there",
which makes it easier to rely on for correctness/etc (which various bits of
infrastructure want, such as Symbols).
Attribute/Type now have `walk` and `replace` methods directly
accessible, which provide power API for interacting with sub elements. As
part of this, a new AttrTypeWalker class is introduced that supports caching
walked attributes/types, and a friendlier API (see the simplification of symbol
walking in SymbolTable.cpp).
Differential Revision: https://reviews.llvm.org/D142272
|
|
It is preferred to merge tosa.transpose operations together rather than convert
one to a tosa.reshape. This is to leverage the tosa.transpose -> tosa.transpose
merging canonicalization.
Reviewed By: AviadCo
Differential Revision: https://reviews.llvm.org/D141434
|
|
When adding an op to the worklist, also add its ancestors to the worklist. This allows for RewritePatterns to match an op `a` based on what is inside of the body of `a`.
This change fixes a problem that became apparent with `vector.warp_execute_on_lane_0`, but could probably be triggered with similar patterns. The pattern extracts an op `b` with `eligible = true` from the body of an op `a`:
```
test.a {
%0 = test.b() {eligible = true}
yield %0
}
```
Afterwards:
```
%0 = test.b() {eligible = true}
test.a {
yield %0
}
```
The pattern is an `OpRewritePattern<OpA>`. For some reason, `test.a` is not on the GreedyPatternRewriter's worklist. E.g., because no pattern could be applied and it was removed. Now, another pattern updates `test.b`, so that `eligible` is changed from `true` to `false`. The `OpRewritePattern<OpA>` could now be applied, but (without this revision) `test.a` is still not on the worklist.
Note: In the above example, an `OpRewritePattern<OpB>` could have been used instead of an `OpRewritePattern<OpA>`. With such a design, we can run into the same problem (when the `eligible` attr is on `test.a` and `test.b` is removed from the worklist because no patterns could be applied).
Note: This change uncovered an unrelated bug in TestSCFUtils.cpp that was triggered due to a change in the order in which ops are processed. A TODO is added to the broken code and test cases are adapted so that the bug is no longer triggered.
Differential Revision: https://reviews.llvm.org/D140304
|
|
used
This gives a better diagnostic in general, because it indicates that the user didn't
close out the last open puncutation range. For example:
```
foo.op {
some.op -> !blah.pointer<
}
```
We want the error to hint about the unclosed `<`, not the `}` (which isn't really in the context of the type).
Differential Revision: https://reviews.llvm.org/D141635
|
|
This is part of the RFC for a better fold API: https://discourse.llvm.org/t/rfc-a-better-fold-api-using-more-generic-adaptors/67374
This patch implements the required foldHook changes and the TableGen machinery for generating `fold` method signatures using `FoldAdaptor` for ops, based on the value of `useFoldAPI` of the dialect. It may be one of 2 values, with convenient named constants to create a quasi enum. The new `fold` method will then be generated if `kEmitFoldAdaptorFolder` is used.
Since the new `FoldAdaptor` approach is strictly better than the old signature, part of this patch updates the documentation and all example to encourage use of the new `fold` signature.
Included are also tests exercising the new API, ensuring proper construction of the `FoldAdaptor` and proper generation by TableGen.
Differential Revision: https://reviews.llvm.org/D140886
|
|
We can fold redundant Tosa::TransposeOp actions like identity tranpose/transpose(traspose).
Reviewed By: rsuderman
Differential Revision: https://reviews.llvm.org/D140466
|
|
Encoding was accidentally left out here even though it forms part of the type.
This is small tightening step and I'll look at follow on to tighten more.
Differential Revision: https://reviews.llvm.org/D140445
|
|
(Reland)
Reland D139447, D139471 With flang actually working
- FunctionOpInterface: make get/setFunctionType interface methods
This patch removes the concept of a `function_type`-named type attribute
as a requirement for implementors of FunctionOpInterface. Instead, this
type should be provided through two interface methods, `getFunctionType`
and `setFunctionTypeAttr` (*Attr because functions may use different
concrete function types), which should be automatically implemented by
ODS for ops that define a `$function_type` attribute.
This also allows FunctionOpInterface to materialize function types if
they don't carry them in an attribute, for example.
Importantly, all the function "helper" still accept an attribute name to
use in parsing and printing functions, for example.
- FunctionOpInterface: arg and result attrs dispatch to interface
This patch removes the `arg_attrs` and `res_attrs` named attributes as a
requirement for FunctionOpInterface and replaces them with interface
methods for the getters, setters, and removers of the relevent
attributes. This allows operations to use their own storage for the
argument and result attributes.
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D139736
|
