I’ll take a look to try and understand the logic of OpAsmInterface and how it handles this case. If OpAsmInterface allows this behaviour, it could be handy, and maybe give a more general solution (i.e., function arguments, blocks, etc).
If there are cases where the printing overrides custom names via OpAsmInterface right now, perhaps to force preservation I could do something like prefixing names during parsing with a magic value (e.g., name = "forcePreserve_" + parsedSsaName;). The printer could check for this, and ensure the printer doesn’t define a new name.
Thinking back to the suggestion about leveraging location information, I’m beginning to see the appeal of re-parsing this at print time. Though it still leaves open the question of how we pass the flag to keep the original identifier names to the printer, as well as the additional complexity of handling operations which have gone through multiple stages of transformation.
Yes, the approach I was taking was to delete the attribute before printing, but if we first pass our IR through several layers of transformation we could end up with unexpected behaviour.
As an illustrative example, when looking at adding the names to the argAttrs of FuncOps, I had to contend with the verifyTrait (Interfaces/FunctionInterfaces.h#L182-L186), which ensured that attributes meet certain conditions. Since dialects can implement arbitrary trait verification, who knows what could happen with the _ssaName attribute.