This makes the IR more readable, in particular when this will be used on
the builtin func outside of the LLVM dialect.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Yeah this is a lot nicer (as clearly evidenced by the llvm.mlir globals as well). For my own edification, is there documentation about the tablegen storageType/convertFromStorage parameters?
mlir/include/mlir/Dialect/LLVMIR/LLVMAttrDefs.td | ||
---|---|---|
34 | Can you drop this. |
Unfortunately not, the best may be: https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/IR/OpBase.td#L823-L836
But it also impact the code generated for the builder of the operation using these attributes. For example the fact that storageType and returnType don't match here:
let storageType = "::mlir::LLVM::LinkageAttr"; let returnType = "::mlir::LLVM::Linkage";
means that when an operation declares a Linkage attribute in its argument list, an extra builder will be generated that takes directly an mlir::LLVM::Linkage enum value (but only because we also define let constBuilderCall = "::mlir::LLVM::LinkageAttr::get($_builder.getContext(), $0)"; which indicates how to build the attribute from the enum value...).
Can you drop this.