Thank your for your comment!
I think this part is problematic. The “charter” of the LLVM dialect is to reflect LLVM IR. If something is supported by the LLVM IR, in this case renaming, we should also look for supporting this in the dialect somehow. That being said, this is only a one-way requirement. We may (and actually do) have something more general in the dialect assuming trivial, implicit and unambiguous translation is possible. Though I’d prefer to keep differences to a minimum to avoid cognitive load.
I believe this is a fair criticism. Note that we don’t currently support renaming (i.e. setName) the way that LLVM IR does, but rather only setting the body (via setBody).
The later might be removed in LLVM IR soon according to Recursive types - #4 by nikic and I don’t mind waiting for that or pushing that change myself if you feel that is necessary.
Allowing structs with identical names I see as an inherent limitation with immutable types as it is difficult to implement the renaming mechanism. I believe the current approach to be a good compromise as it is semantically more permissive and a superset of the semantics of LLVM IR proper that imports and exports with identical execution semantics.
To make progress on this, please consider how importing from LLVM IR would operate, in particular in presence of multiple LLVM IR modules with named structs in them that are being placed into one MLIR meta-module, there is a use case of that in, e.g., some Polygeist workflows.
When importing one LLVM IR module, all struct types are guaranteed to have a unique name. The corresponding struct types in MLIR will therefore also have unique names and semantics identical.
In the multi-module case, the difference that may occur is that both modules may have structs with the exact same name and bodies. If one were to merge in LLVM IR, these would get renamed to preserve nominal type inequality. When merging in MLIR with immutable structs, the two struct types would be seen as identical types and have type equality. When exporting back to LLVM IR this would make the types more permissive (via merging), but execution semantics preserved.
I’d love to hear more if you think this could break things anywhere in e.g. Polygeist or elsewhere