print: align adjacent multi-version columns' lines, to match up their anchors. #18
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This extra step, just before turning multi-version pretty-printed fragments into a HTML table row, allows for a clearer visual match between the columns, turning the multi-version mode into something closer to a pass "differ", but the use of anchors (instead of line contents) makes it more conservative, reliable and somewhat simpler.
In short, if two adjacent versions contain a definition like
v123 = ...
, it should now end up on the same horizontal line in both versions (assuming it's not e.g. out of order wrt most of the other definitions).Before, adding or removing instructions (or even their pretty-printing needing different line amounts) would result in one side being behind (and the other, ahead), which would accumulate (even if most of their contents might be similar or even identical). With this PR, a lot of that should be alleviated, as padding (of empty lines) is added to keep both versions aligned as much as possible.
However, while it works great for correcting small misalignments (the original usecase), it's quite zealous (and lacks any heuristics or further constraint-solving etc.), leading to results like this:
(click for complete
pretty HTML example)
(click for complete
pretty HTML example)
This is for the same SPIR-T as the last screenshot from the Rust-GPU
reduce
+fuse_selects
PR.The
OpNop
s don't help (and those should be gone once SPIR-T APIs are adjusted), but it's generally much worse looking than I was hoping. Maybe it's worth it for the ability, but some things are just annoying.Based on this screenshot alone, several possible further improvements come to mind:
(EDIT: several of these have been implemented in this PR since it was opened)
hidden anchors could be added for e.g.ControlNode
s andControlRegion
s, even if there's not necessarily any syntax to attach them to (other than the keyword for non-Block
ControlNode
s and the{...}
brackets forControlRegion
?)the contents of the aligned lines could be compared and some kind of graying/translucency used to de-emphasize the lines that haven't changedthere's a risk here of making them confused with removed linesthis is where merely partial grayscaling, or some kind of sepia effect, might come in handysuch diff-like mode could supplant the use ofcolspan
entirely, and allow horizontal scrolling of the whole table, with the max line length being used to size the cells (e.g.td { max-width: 100ch; }
), instead of divvying up the whole viewport width--spirt-dump-passes
could skip the unstructured control-flow column, which adds a bunch of gaps for no good reason (or it could be kept but with the alignment turned off?)(sadly, we can't just switch where the vertical gap goes unconditionally: anchors can easily precede multiple-line contents that should not be broken up)
LineOp
more directly, or just making indentation special inTextOp
)print::pretty
layout, to allow "flexible vertical spacing", which frankly seems like overkill