Support extra concrete class declarations and definitions under NativeTrait that get injected into the class that specifies the trait. Extra declarations and definitions can be passed in as template arguments for NativeOpTraitNativeAttrTrait and NativeTypeTrait.
Usage examples of this feature include:
- Creating a wrapper Trait for authoring inferReturnTypes with the OpAdaptor by specifying necessary Op specific declarations and definitions directly in the trait
- Refactoring the InferTensorType trait
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D154731
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
The snippets had several problems including mismatching argument names,
stray or missing symbols, and missing updates to changes in transform
ops. I also rewrapped those comments in the snippets that I touchted
that exceeded 80 characters.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D154817
- Fix include paths for Transform Dialect Tutorial
- Add math dialect's pass into Pass.md
- Remove a include path of Quant dialect from Pass.md
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D153944
All `apply` functions now have a `TransformRewriter &` parameter. This rewriter should be used to modify the IR. It has a `TrackingListener` attached and updates the internal handle-payload mappings based on rewrites.
Implementations no longer need to create their own `TrackingListener` and `IRRewriter`. Error checking is integrated into `applyTransform`. Tracking listener errors are reported only for ops with the `ReportTrackingListenerFailuresOpTrait` trait attached, allowing for a gradual migration. Furthermore, errors can be silenced with an op attribute.
Additional API will be added to `TransformRewriter` in subsequent revisions. This revision just adds an "empty" `TransformRewriter` class and updates all `apply` implementations.
Differential Revision: https://reviews.llvm.org/D152427
The MLIR LSP server initially had plans to support running passes from the
client, but this was never implemented. The doc unnecessarily advise to
register passes and makes reference to LSP server having some interaction
with passes.
Differential Revision: https://reviews.llvm.org/D153046
This patch is improves upon https://reviews.llvm.org/D152621. There, I pointed out some issues with D152621, which I'll repeat here.
> Passes use a different logic for generating the documentation; which I didn't update to be in-line with this change.
Fixed by defining and using `mlir::tblgen::emitSummary`. This is now used in `OpDocGen.cpp` and `PassDocGen.cpp`.
Note that the passes documentation currently prints the summary behind the pass argument. For example:
```
#### -arm-neon-2d-to-intr: Convert Arm NEON structured ops to intrinsics
```
at https://mlir.llvm.org/docs/Passes/#-promote-buffers-to-stack-promotes-heap-based-allocations-to-automatically-managed-stack-based-allocations.
This currently differs from how the summary is printed for Ops. For example:
```
#### amdgpu.lds_barrier (::mlir::amdgpu::LDSBarrierOp) ¶
**Summary:** _Barrier that includes a wait for LDS memory operations._
```
at https://mlir.llvm.org/docs/Dialects/AMDGPU/#amdgpulds_barrier-mliramdgpuldsbarrierop.
The changes in this patch ensure that:
1. The summary is always printed on a new line.
2. The summary is always printed in italic.
3. The summary always starts with a capital letter.
I've dropped the `**Summary:**`, which was introduced in D152621, because only italicization should be already clear enough.
> `amx.tdpbssd` shows **Summary:** __ meaning that apparently hasSummary does not guarantee a non-empty summary.
This is fixed by double-checking `!summary.empty()`, because the following code
```cpp
void mlir::tblgen::emitSummary(StringRef summary, raw_ostream &os) {
if (!summary.empty()) {
char first = std::toupper(summary.front());
llvm::StringRef rest = summary.drop_front();
os << "\n_" << first << rest << "_\n\n";
} else {
os << "\n_" << "foo" << "_\n\n";
}
}
```
generates the following Markdown:
```
### `amx.tdpbssd` (::mlir::amx::x86_amx_tdpbssd)
_foo_
```
in `tools/mlir/docs/Dialects/AMX.md`.
> Summary fields containing * cancel the italicization, so the * should probably be escaped to solve this. EDIT: Nope. This is because mlir-www runs Hugo 0.80 whereas 0.111 correctly parses _Raw Buffer Floating-point Atomic Add (MI-* only)_ as an italicized string.
This will be fixed by https://github.com/llvm/mlir-www/pull/152.
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D152648
This patch fixes the equations on the Quantization page
(https://mlir.llvm.org/docs/Quantization/).
I don't know what caused the equations to be broken, it
might be https://github.com/llvm/mlir-www/pull/152, but
I'm not sure. Irregardless, let's just fix it and be
done with it.
I've fixed the equations by moving some subscripts to
the text. For some reason, the large number of subscripts
caused Mathjax to fail. I've also tried KaTeX, which
failed at exactly the same number of subscripts.
The workflow to inspect the fix is as follows:
```
$ git clone --depth=1 https://github.com/llvm/mlir-www.git /some/path/mlir-www
$ git clone --depth=1 https://github.com/llvm/llvm-project.git /some/path/llvm-project
$ cp /some/path/llvm-project/mlir/docs/Quantization.md \
/some/path/mlir-www/website/content/Quantization.md
$ cd /some/path/mlir-www/website
$ hugo serve
[...]
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop
```
and view the page at http://localhost:1313/Quantization/.
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D152651
The call to 'multiply_transpose' in the initialization of the variable 'f' was
intended to have a shape mismatch. However the variable 'a' has shape <2, 3> and
the variable 'c' has shape <3, 2>, so the arguments 'transpose(a)' and 'c' have
in fact compatible shapes (<3, 2> both), the opposite of what is wanted here.
This commit removes the transpose so that arguments 'a' and 'c' have
incompatible shapes <2, 3> and <3, 2>, respectively.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D151897
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
The transform dialect has been around for a while and is sufficiently
stable at this point. Add the first three chapters of the tutorial
describing its usage and extension.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D151491
For block arg locs a common case is no/uknown location (where the producer
signifies they don't care about blockarg location). Also avoid needing to
dynamically resize opnames during parsing.
Assumed to be post lazy loading change, so chose version 3.
Differential Revision: https://reviews.llvm.org/D151038
This patch implements a mechanism to read/write use-list orders from/to the mlir bytecode format. When producing bytecode, use-list orders are appended to each value of the IR. When reading bytecode, use-lists orders are loaded in memory and used at the end of parsing to sort the existing use-list chains.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D149755
IsolatedRegions are emitted in sections in order for the reader to be
able to skip over them. A new class is exposed to manage the state and
allow the readers to load these IsolatedRegions on-demand.
Differential Revision: https://reviews.llvm.org/D149515
- Added missing TensorTransformOps to the Transform doc
- Added missing AMDGPUPasses to the Passes doc
- Place `async dialect` in alphabetical order in the Passes doc
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D150341
According to the EBNF syntax described in the 'Common syntax' chapter,
literal characters should be surrounded by backticks (`). However, in
some sections of this document, single quotes (') are used instead.
So, fix them.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D150067
Currently `CallOpInterface` has a method `getCallableForCallee` to have a consistent way to get the callee from an operation with `CallOpInterface`, but missing a consistent way to set a callee for an operation with `CallOpInterface`.
A set callee method is useful for transformations that operate on `CallOpInterface`, and change the callee, e.g., a pass that specialize function, which clone the callee, and change the `CallOpInterface`'s callee to the cloned version. Without such method, transformation would need to understand the implementation for every operations with `CallOpInterface`, and have a type switch to handle them.
This review adds a method to set callee for operation with `CallOpInterface`.
Reviewed By: gysit, zero9178o
Differential Revision: https://reviews.llvm.org/D149763
When tooling out there produces a reproducer that is archived, the first thing
a user is likely to expect is to process this as they do with any MLIR file.
However https://reviews.llvm.org/D126447 changed the behavior of mlir-opt to
eliminate the `--run-reproducer` option and instead automatically run it when
present in the input file. This creates a discrepancy in how mlir-opt behaves
when fed with an input file, and is surprising for users.
The explicit passing of `--run-reproducer` to express user-intent seems more
in line with what is expected from `mlir-opt`.
Reviewed By: rriddle, jpienaar
Differential Revision: https://reviews.llvm.org/D149820
They don't convey any useful information and make the documentation
unnecessarily hard to read.
Differential Revision: https://reviews.llvm.org/D149641
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 d572cd1b06 after fixing python bindings build.
Differential Revision: https://reviews.llvm.org/D141742
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
Add a set of transform operations into the "structured" extension of the
Transform dialect that allow one to select transformation targets more
specifically than the currently available matching. In particular, add
the mechanism for identifying the producers of operands (input and init
in destination-passing style) and users of results, as well as
mechanisms for reasoning about the shape of the iteration space.
Additionally, add several transform operations to manipulate parameters
that could be useful to implement more advanced selectors. Specifically,
new operations let one produce and compare parameter values to implement
shape-driven transformations.
New operations are placed in separate files to decrease compilation
time. Some relayering of the extension is necessary to avoid repeated
generation of enums.
Depends on D148013
Depends on D148014
Depends on D148015
Reviewed By: chelini
Differential Revision: https://reviews.llvm.org/D148017
The new class hierarchy is as follows:
* `IntegerRelation` (no change)
* `IntegerPolyhedron` (no change)
* `FlatLinearConstraints`: provides an AffineExpr-based API
* `FlatLinearValueConstraints`: stores an additional mapping of non-local vars to SSA values
* `FlatAffineValueConstraints`: provides additional helper functions for Affine dialect ops
* `FlatAffineRelation` (no change)
`FlatConstraints` and `FlatValueConstraints` are moved from `MLIRAffineAnalysis` to `MLIRAnalysis` and can be used without depending on the Affine dialect.
This change is in preparation of D145681, which adds an MLIR interface that depends on `FlatConstraints` (and cannot depend on the Affine dialect or any other dialect).
Differential Revision: https://reviews.llvm.org/D146201
This patch introduces the poison constant from LLVM in the LLVM IR dialect. It also adds import and export support for it, along with roundtrip tests.
Reviewed By: gysit
Differential Revision: https://reviews.llvm.org/D146631
The revision adds the handleArgument and handleResult handlers that
allow users of the inlining interface to implement argument and result
conversions that take argument and result attributes into account. The
motivating use cases for this revision are taken from the LLVM dialect
inliner, which has to copy arguments that are marked as byval and that
also has to consider zeroext / signext when converting integers.
All type conversions are currently handled by the
materializeCallConversion hook. It runs before isLegalToInline and
supports only the introduction of a single cast operation since it may
have to rollback. The new handlers run shortly before and after
inlining and cannot fail. As a result, they can introduce more complex
ir such as copying a struct argument. At the moment, the new hooks
cannot be used to perform type conversions since all type conversions
have to be done using the materializeCallConversion. A follow up
revision will either relax this constraint or drop
materializeCallConversion in favor of the new and more flexible
handlers.
The revision also extends the CallableOpInterface to provide access
to the argument and result attributes if available.
Reviewed By: rriddle, Dinistro
Differential Revision: https://reviews.llvm.org/D145582
A dialect can opt-in to handle versioning through the
`BytecodeDialectInterface`. Few hooks are exposed to the dialect to allow
managing a version encoded into the bytecode file. The version is loaded
lazily and allows to retrieve the version information while parsing the input
IR, and gives an opportunity to each dialect for which a version is present
to perform IR upgrades post-parsing through the `upgradeFromVersion` method.
Custom Attribute and Type encodings can also be upgraded according to the
dialect version using readAttribute and readType methods.
There is no restriction on what kind of information a dialect is allowed to
encode to model its versioning. Currently, versioning is supported only for
bytecode formats.
Reviewed By: rriddle, mehdi_amini
Differential Revision: https://reviews.llvm.org/D143647
- Fix a place of NVGPU dialect's pass
- Move a summary of `-finalize-memref-to-llvm` into description
- Fix broken links
- Replace back-quote dialect headers with single-quote headers for
improved readability.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D142868
In MLIR tutorial example code, use `Pure` to remove the side-effects of
operations. Update the document to be consistent with the example code.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D143814
Introduce support for the third kind of values in the transform dialect:
value handles. Similarly to operation handles, value handles are
pointing to a set of values in the payload IR. This enables
transformation to be targeted at specific values, such as individual
results of a multi-result payload operation without indirecting through
the producing op or block arguments that previously could not be easily
addressed. This is expected to support a broad class of memory-oriented
transformations such as selective bufferization, buffer assignment, and
memory transfer management.
Value handles are functionally similar to operation handles and require
similar implementation logic. The most important change concerns the
handle invalidation mechanism where operation and value handles can
affect each other.
This patch includes two cleanups that make it easier to introduce value
handles:
- `RaggedArray` structure that encapsulates the SmallVector of
ArrayRef backed by flat SmallVector logic, frequently used in the
transform interfaces implementation;
- rewrite the tests that associated payload handles with an integer
value `reinterpret_cast`ed as a pointer, which were a frequent
source of confusion and crashes when adding more debugging
facilities that can inspect the payload.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D143385
This allows discouraging the use of specific build methods of an op by having TableGen generate C++ code, instructing the C++ compiler to warn on use of the `build` method.
The implementation uses the C++14 `[[deprecated(...)]]`` for this purpose. I considered using `LLVM_DEPRECATED`, but thought requiring a fix-it was not necassery, nor would the syntax in ODS have been very nice.
My motivation for this change is that in the future I'd like to deprecate the use `build` methods in the LLVM Dialect, not using explicit pointer types for ops such as `llvm.load` or `llvm.alloca`, which makes the code not future proof for opaque pointers. In-tree has to be clean first before I could commit such a change of course, but I thought the initial infrastructure change could already be submitted.
Differential Revision: https://reviews.llvm.org/D143190
