LLVM Discussion Forums

Names in SSA values for debuggability


Following up on:

We have pretty names on SSA values thanks to the patch, however since a name attribute was used, CSE pass would not eliminate 2 ops with different names even if they are doing the same thing, since an attribute was different.

Is there a way to add the pretty name to the SSA value but CSE pass still ignores it?

Or alternatively, is there a way to set an Attribute(or something else) on an op which is meaningless to all but the printer?

Once one starts having 17000 ops from applying fission to networks like InceptionV3 or ResNet, it would be really useful to know which value came from which layer.


Unfortunately we don’t have a solution for “debug name”. The thread you’re referring to is explicitly about “load bearing” names, not just “pretty names for debuggability”, so it works as intended right now by preventing CSE.
I’d love to get debug names for SSA values, but it really isn’t easy to get in MLIR right now.

You would need something like the LLVM metadata system, which can be dropped without breaking correctness. In practice, I don’t think the LLVM design has worked very well though…

Couldn’t we have a PrettyNameLoc and some special printer/parser handling for it?

Or just a custom printer that prints a mapping of the location at the use site (add(%2 from "layer1", %4 from "layer2") : tensor<...>) and so reuse location info without adding attribute, and the custom printer would need a mapping function as input to go from full location to some shorter form, but all customizable is in printing for debugging then.

Thanks for the responses everyone,

I think this sounds good, my understanding(which could be wrong, so bear with me) is, Location is also an Attribute and it is quite special, it is different for each op, can be dropped at anytime and no pass cares for it which seems to be exactly the behavior we want out of CSE here (I already confirmed this is working).

Only bit missing is for SSA value printing to use the name coming from NameLoc’s name identifier (if one is available), that is where writing a custom printer and parser for our dialect comes in I suppose.

Very exciting, I will try it out and update the thread with my results, thanks again!

1 Like

Just to clarify here: Location reuse the Attribute uniquing/storage facilities as an implementation detail, but isn’t stored as an attribute on the Operation.
The Operation class stores directly a Location as a member and not as part of its attributes.

Thanks Mehdi, yes that makes complete sense, and explains why location is ignored by the CSE Pass too.

Yes, this is a really good idea.

It can be dropped only by creating a new op that doesn’t have the location. But for a given op, its location won’t get dropped (that is different from LLVM’s behavior).

Or for any locations. E.g., going from fusedloc to a shorter printed form is possible (take say longest common prefix of fused locs, then pass that through to namedloc “prettifier”), but there may not be a universally agreed upon manner :slight_smile: .

If this is only for debugging then only printing might be needed (see prettyForm debug info), but would mean that you can’t roundtrip it, which would reduce utility but requires less changes (a quick and dirty prototype could be done locally).

So this would be (short name, location)? Similar to FusedLoc with metadata fixed to require a string attr? How would it interact with optimization passes and location fusion? E.g., today we create a FusedLoc from the op’s locations being fused (well commonly, need not always), if there is a special PrettyNameLoc then it would seem that we might want it inverted (fusing two PrettyNameLoc results in a PrettyNameLoc with FusedLoc of the locations rather than a FusedLoc of two PrettyNameLocs)