| Issue |
89940
|
| Summary |
Generic Operation builder does not set up properties
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
jschj
|
We use some of the auto-generated “generic” builders with return type inference for some our operations in our code base. They roughly look like this:
```
void MyOp::build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::ValueRange operands, ::llvm::ArrayRef<::mlir::NamedAttribute> attributes) {
assert(operands.size() >= 1u && "mismatched number of parameters");
odsState.addOperands(operands);
odsState.addAttributes(attributes);
::llvm::SmallVector<::mlir::Type, 2> inferredReturnTypes;
if (::mlir::succeeded(MyOp::inferReturnTypes(odsBuilder.getContext(),
odsState.location, operands,
odsState.attributes.getDictionary(odsState.getContext()),
odsState.getRawProperties(),
odsState.regions, inferredReturnTypes))) {
assert(inferredReturnTypes.size() == 1u && "mismatched number of return types");
odsState.addTypes(inferredReturnTypes);
} else {
::llvm::report_fatal_error("Failed to infer result type(s).");
}
}
```
The problem is that at no point the properties are set up. The other builders (the ones where the individual operands are provided) do eventually call `odsState.getOrAddProperties<Properties>();`. This poses a problem in our case since we rely on operandSegmentSizes (which is a property) to be correctly set up. This issue is happening with the release version of LLVM18.
To reproduce someone might simply look at the generated "generic" builders of any operation with properties.
[Discourse link](https://discourse.llvm.org/t/generic-operation-builder-does-not-set-up-properties/78552)
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
