[Mlir-commits] [mlir] [mlir][LLVM] handle ArrayAttr for constant array of structs (PR #139724)
Tobias Gysi
llvmlistbot at llvm.org
Wed May 14 04:00:25 PDT 2025
gysit wrote:
> By more restrictive, do you mean rejecting the ArrayAttr on an mlir::Constant for an array whose element is not a struct type?
Yes that was my though. I believe for floats / integers etc we use a ElementsAttr or even a SplatElementsAttr to ensure the types are consistent. ArrayAttr should really be our last resort since consistency is hard to verify.
> I did not do it because although the ModuleTranslation did not support it, the verifier was already accepting those, so I wondered if someone had a use case for that purely in the LLVM MLIR dialect.
I assume this is a gap in the verifier but maybe there are users nevertheless.
> I am open to alternatives if you see a better path for my goal.
I think highest priority is probably trying to make the verifier more readable.
Second priority would be having something like a SplatLLVMStructElementsAttr / DenseLLVMStructElementsAttr. That would offload a lot of the verification work to these attributes and would make the verifier much nicer. Also a splat attribute would be much more efficient if all elements are initialized to the same value.
Unfortunately, I am not sure how easy it is to add such attributes that extend the existing built-in splat / dense array attributes. At least, there seem to be some base classes that probably could be extended (such as `ElementsAttrBase`). However, properly supporting nesting for arrays and structs etc is probably quite difficult. So for sure consider this optional.
@Dinistro @matthias-springer do you have an idea if it would be feasible / make sense to strive for something like Splat/Dense LLVMStruct/LLVMArray ElementsAttr?
https://github.com/llvm/llvm-project/pull/139724
More information about the Mlir-commits
mailing list