Add `gen-type-constraint-decls` and `gen-type-constraint-defs`, which
generate public C++ functions for type constraints. The name of the C++
function is specified in the `cppFunctionName` field.
Type constraints are typically used for op/type/attribute verification.
They are also sometimes called from builders and transformations. Until
now, this required duplicating the check in C++.
Note: This commit just adds the option for type constraints, but
attribute constraints could be supported in the same way.
Alternatives considered:
1. The C++ functions could also be generated as part of
`gen-typedef-decls/defs`, but that can be confusing because type
constraints may rely on type definitions from multiple `.td` files.
`#include`s could cause duplicate definitions of the same type
constraint.
2. The C++ functions could also be generated as static member functions
of dialects, but they don't really belong to a dialect. (Because they
may rely on type definitions from multiple dialects.)
While we have had a Properties.td that allowed for defining
non-attribute-backed properties, such properties were not plumbed
through the basic autogeneration facilities available to attributes,
forcing those who want to migrate to the new system to write such code
by hand.
## Potentially breaking changes
- The `setFoo()` methods on `Properties` struct no longer take their
inputs by const reference. Those wishing to pass non-owned values of a
property by reference to constructors and setters should set the
interface type to `const [storageType]&`
- Adapters and operations now define getters and setters for properties
listed in ODS, which may conflict with custom getters.
- Builders now include properties listed in ODS specifications,
potentially conflicting with custom builders with the same type
signature.
## Extensions to the `Property` class
This commit adds several fields to the `Property` class, including:
- `parser`, `optionalParser`, and `printer` (for parsing/printing
properties of a given type in ODS syntax)
- `storageTypeValueOverride`, an extension of `defaultValue` to allow
the storage and interface type defaults to differ
- `baseProperty` (allowing for classes like `DefaultValuedProperty`)
Existing fields have also had their documentation comments updated.
This commit does not add a `PropertyConstraint` analogous to
`AttrConstraint`, but this is a natural evolution of the work here.
This commit also adds the concrete property kinds `I32Property`,
`I64Property`, `UnitProperty` (and special handling for it like for
UnitAttr), and `BoolProperty`.
## Property combinators
`Properties.td` also now includes several ways to combine properties.
One is `ArrayProperty<Property elem>`, which now stores a
variable-length array of some property as
`SmallVector<elem.storageType>` and uses `ArrayRef<elem.storageType>` as
its interface type. It has `IntArrayProperty` subclasses that change its
conversion to attributes to use `DenseI[N]Attr`s instead of an
`ArrayAttr`.
Similarly, `OptionalProperty<Property p>` wraps a property's storage in
`std::optional<>` and adds a `std::nullopt` default value. In the case
where the underlying property can be parsed optionally but doesn't have
its own default value, `OptionalProperty` can piggyback off the optional
parser to produce a cleaner syntax, as opposed to its general form,
which is either `none` or `some<[value]>`.
(Note that `OptionalProperty` can be nested if desired).
## Autogeneration changes
Operations and adaptors now support getters and setters for properties
like those for attributes. Unlike for attributes, there aren't separate
value and attribute forms, since there is no `FooAttr()` available for a
`getFooAttr()` to return.
The largest change is to operation formats. Previously, properties could
only be used in custom directives. Now, they can be used anywhere an
attribute could be used, and have parsers and printers defined in their
tablegen records.
These updates include special `UnitProperty` logic like that used for
`UnitAttr`.
## Misc.
Some attempt has been made to test the new functionality.
This commit takes tentative steps towards updating the documentation to
account for properties. A full update will be in order once any followup
work has been completed and the interfaces have stabilized.
---------
Co-authored-by: Mehdi Amini <joker.eph@gmail.com>
Co-authored-by: Christian Ulmann <christianulmann@gmail.com>
- Some sentences are incorrectly split across list items.
- Some pre-formatted syntax is left in plaintext
- Some lines end in spaces
Co-authored-by: Jeremy Kun <j2kun@users.noreply.github.com>
`attr-dict` currently prints any attribute (inherent or discardable)
that does not occur elsewhere in the assembly format. `prop-dict` on the
other hand, always prints and parses all properties (including inherent
attributes stored as properties) as part of the property dictionary,
regardless of whether the properties or attributes are used elsewhere.
(with the exception of default-valued attributes implemented recently in
https://github.com/llvm/llvm-project/pull/87970).
This PR changes the behavior of `prop-dict` to only print and parse
attributes and properties that do not occur elsewhere in the assembly
format. This is achieved by 1) adding used attributes and properties to
the elision list when printing and 2) using a custom version of
`setPropertiesFromAttr` called `setPropertiesFromParsedAttr` that is
sensitive to the assembly format and auto-generated by ODS.
The current and new behavior of `prop-dict` and `attr-dict` were also
documented.
Happens to also fix https://github.com/llvm/llvm-project/issues/88506
References to headings need to be preceded with a slash. Also,
references to headings on the same page do not need to contain the name
of the document (omitting the document name means if the name changes
the links will still be valid).
I double checked the links by building [the
website](https://github.com/llvm/mlir-www):
```shell
./mlir-www-helper.sh --install-docs ../llvm-project website
cd website && hugo serve
```
It seems the `Traits.md` file was turned into `Traits/_index.md` in
https://reviews.llvm.org/D153291, causing links to `Traits.md` to no
longer work (instead, `Traits` needs to be used).
I've been struggling with generating the C++ class declarations and definitions for custom attributes from TableGen, as described on this documentation page: https://mlir.llvm.org/docs/DefiningDialects/AttributesAndTypes/#adding-a-new-attribute-or-type-definition
The code for custom types is automatically generated when the MLIR Dialect is added with `add_mlir_dialect()` in the CMake file.
The same is not the case for custom attributes. I think people could benefit from learning how to adjsut their CMakeLists.txt to automatically generate the classes as described on that documentation page. This change adds the necessary information for this.
makslevental on Discord was so kind to help me figure this out myself
Reviewed By: makslevental
Differential Revision: https://reviews.llvm.org/D155249
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 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
The vast majority of parameters of C++ types used as parameters for Attributes and Types are likely to be default constructible. Nevertheless, TableGen conservatively generates code for the custom directive, expecting signatures using FailureOr<T> for all parameter types T to accomodate them possibly not being default constructible. This however reduces the ergonomics of the likely case of default constructible parameters.
This patch fixes that issue, while barely changing the generated TableGen code, by using a helper function that is used to pass any parameters into custom parser methods. If the type is default constructible, as deemed by the C++ compiler, a default constructible instance is created and passed into the parser method by reference. In all other cases it is a Noop and a FailureOr is passed as before.
Documentation was also updated to document the new behaviour.
Fixes https://github.com/llvm/llvm-project/issues/60178
Differential Revision: https://reviews.llvm.org/D142301
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
This is part of an effort to migrate from llvm::Optional to
std::optional. This patch changes the way mlir-tblgen generates .inc
files, and modifies tests and documentation appropriately. It is a "no
compromises" patch, and doesn't leave the user with an unpleasant mix of
llvm::Optional and std::optional.
A non-trivial change has been made to ControlFlowInterfaces to split one
constructor into two, relating to a build failure on Windows.
See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Signed-off-by: Ramkumar Ramachandra <r@artagnon.com>
Differential Revision: https://reviews.llvm.org/D138934
This moves the documentation for defining dialects, attributes/types,
and operations into a new `DefiningDialects` folder. This helps to
keep the documentation grouped together, making it easier to find
related documentation.
Differential Revision: https://reviews.llvm.org/D137594
