Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

N001 [000371]   LCL_VAR   V01 loc0         u:ssa41 (last use) => $12b {ADD($42, $12a)}
N004 [000369]   LCL_VAR   V01 loc0         d:ssa42 => $VN.Void
Tree [000368] assigned VN to local var V01/ssa42: $12c {ADD($42, $12b)}
SSA PHI definition: set VN of local V08/ssa3 to $146 {PhiDef($8, $3, $101)} .
SSA PHI definition: set VN of local V01/ssa46 to $147 {PhiDef($1, $2e, $10d)} .
The SSA definition for ByrefExposed (ssa1) at start of BB23 is $c0 {InitVal($41)}
The SSA definition for GcHeap (ssa1) at start of BB23 is $c0 {InitVal($41)}

@AndyAyersMS @dotnet/jit-contrib PTAL

I kind of like the current . default though as you note it's not search friendly. How about something like @? I don't think we use it for much right now.

V28@3 seems to flow pretty well.

I kind of like the current . default
V28@3 seems to flow pretty well.

May be V28@ssa3 so we can easily search for @ssa throughout the dump file for occurances where SSA is displayed as being tied to variables?

@ is used extensively in the LSRA dumps, which would make it ambiguous.

I'm very biased towards something that is context-free searchable. My peculiar preference is something that works with vi's default settings for the '*' and '#' search commands.

@ is used extensively in the LSRA dump

Yep, and that's why I was suggesting to append with ssa, but I see your point.

@ is used extensively in the LSRA dumps, which would make it ambiguous.

I'm very biased towards something that is context-free searchable. My peculiar preference is something that works with vi's default settings for the '*' and '#' search commands.

SSA no longer relevant once we get to LSRA, so it seems like this wouldn't be too much of a problem?

Or we could use some other single char that we don't use when dumping flags, like / or ^ or ...?

It looks like we don't use ^ or % or & in the dumps.

^ is problematic for vi / regex because it needs to be escaped

@AndyAyersMS Maybe you can describe more specifically what you don't like about ssa%u or what you would prefer?

We have some similar examples: statements: "STMT%05d", nodes: "N%03d", CSE: "CSE #%02u" (I'd prefer "cse%02u").

Even using "S%u" might be unique enough, but certainly isn't as obvious to the newcomer (to the JIT or phase).

It looks like we don't use ^ or % or & in the dumps.

^ is problematic for vi / regex because it needs to be escaped

@AndyAyersMS Maybe you can describe more specifically what you don't like about ssa%u or what you would prefer?

We have some similar examples: statements: "STMT%05d", nodes: "N%03d", CSE: "CSE #%02u" (I'd prefer "cse%02u").

Even using "S%u" might be unique enough, but certainly isn't as obvious to the newcomer (to the JIT or phase).

The ssa number on its own is not very interesting. We should always display it as a suffix of the var, eg V02.1 or similar and not as a separate side annotation like we do now. Then the separator syntax won't matter since the var num will be the main part of the search key.

I'm going to close this for now.