You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
print: fix intra-func (e.g. values) numbering to use print order instead of breadth-first. (#15)
This is a bit of an abstract problem, but hopefully this comparison
shows the problem:
<table>
<tr><th>Before</th><th>After</th></tr>
<tr>
<td>
```rs
// Note the "leaps" (e.g. v2 -> v5),
// as the indentation level increases.
v1 = …
v2 = …
if v2 {
v5 = …
if v5 {
v9 = …
v10 = …
}
v6 = …
}
v3 = …
if v3 {
v7 = …
v8 = …
}
v4 = …
// ^ last top-level is v4 so the
// next level in will start at v5
```
</td>
<td>
```rs
// The value numbering should
// now match the textual order.
v1 = …
v2 = …
if v2 {
v3 = …
if v3 {
v4 = …
v5 = …
}
v6 = …
}
v7 = …
if v7 {
v8 = …
v9 = …
}
v10 = …
// ^ last top-level (v10) is
// now the last one overall
```
</td>
</tr>
</table>
While the discrepancy isn't huge on this small artificial example, in
practice the leap could be from e.g. 3-digit to 4-digit numbers, which
wasn't just jarring but also made the dataflow hard to follow.
This entire time I just assumed I was looking at values defined by later
passes, but it turned out to be the result of region-level traversal
(instead of handling all regions and nodes in regular `visit` order),
and I only spotted it while tweaking this code, for a later change
involving debuginfo (inlined call sites etc.).
0 commit comments