[Mlir-commits] [mlir] [mlir][LLVM] handle ArrayAttr for constant array of structs (PR #139724)

[Tobias Gysi]

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