caio/clang-p2996
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Revert "[mlir][ODS] Add a generated builder that takes the Properties struct" (#130117)

Browse Source 
Reverts llvm/llvm-project#124713.

Builders involving sanitizers are failing:
https://lab.llvm.org/buildbot/#/builders/169/builds/9106.
This commit is contained in:
Benjamin Chetioui
2025-03-06 16:31:10 +01:00
committed by GitHub
parent ff993f9a4c
commit 32f543760c
10 changed files with 49 additions and 227 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
mlir/docs/DeclarativeRewrites.md
View File

@@ -237,9 +237,9 @@ In the above, we are using `BOp`'s result for building `COp`.
Given that `COp` was specified with table-driven op definition, there will be
several `build()` methods generated for it. One of them has aggregated
parameters for result types, operands, and properties in the signature: `void
parameters for result types, operands, and attributes in the signature: `void
COp::build(..., ArrayRef<Type> resultTypes, Array<Value> operands,
const COp::Properties& properties)`. The pattern in the above calls this `build()`
ArrayRef<NamedAttribute> attr)`. The pattern in the above calls this `build()`
method for constructing the `COp`.
In general, arguments in the result pattern will be passed directly to the

27
mlir/docs/DefiningDialects/Operations.md
View File

@@ -465,18 +465,7 @@ def MyOp : ... {
The following builders are generated:
```c++
// All result-types/operands/properties/discardable attributes have one
// aggregate parameter. `Properties` is the properties structure of
// `MyOp`.
static void build(OpBuilder &odsBuilder, OperationState &odsState,
TypeRange resultTypes,
ValueRange operands,
Properties properties,
ArrayRef<NamedAttribute> discardableAttributes = {});
// All result-types/operands/attributes have one aggregate parameter.
// Inherent properties and discardable attributes are mixed together in the
// `attributes` dictionary.
static void build(OpBuilder &odsBuilder, OperationState &odsState,
TypeRange resultTypes,
ValueRange operands,
@@ -509,28 +498,20 @@ static void build(OpBuilder &odsBuilder, OperationState &odsState,
// All operands/attributes have aggregate parameters.
// Generated if return type can be inferred.
static void build(OpBuilder &odsBuilder, OperationState &odsState,
ValueRange operands,
Properties properties,
ArrayRef<NamedAttribute> discardableAttributes);
// All operands/attributes have aggregate parameters.
// Generated if return type can be inferred. Uses the legacy merged attribute
// dictionary.
static void build(OpBuilder &odsBuilder, OperationState &odsState,
ValueRange operands, ArrayRef<NamedAttribute> attributes);
// (And manually specified builders depending on the specific op.)
```
The first two forms provide basic uniformity so that we can create ops using
the same form regardless of the exact op. This is particularly useful for
The first form provides basic uniformity so that we can create ops using the
same form regardless of the exact op. This is particularly useful for
implementing declarative pattern rewrites.
The third and fourth forms are good for use in manually written code, given that
The second and third forms are good for use in manually written code, given that
they provide better guarantee via signatures.
The fourth form will be generated if any of the op's attribute has different
The third form will be generated if any of the op's attribute has different
`Attr.returnType` from `Attr.storageType` and we know how to build an attribute
from an unwrapped value (i.e., `Attr.constBuilderCall` is defined.)
Additionally, for the third form, if an attribute appearing later in the