Combine location information with debug sources

[nazar-pc]

See Rust-GPU/rust-gpu#323 (comment) for original discussion.

Right now RUSTGPU_CODEGEN_ARGS="--dump-spirt-passes=$PWD/spirt-passes" results in HTML, which contains file paths and line numbers (helpful!), but not the actual source code (would be very helpful too!).

It is extremely useful to see Rust source code and SPIR-T it was compiled to side by side. There is already Rust-GPU/rust-gpu#201, I'd expect the output to look something similar to its interface: maybe two synchronized columns, which allows easy comparison.

There is also https://github.com/pacak/cargo-show-asm for an example of what it might look like in CLI.

Basically any solution of that kind would go a long way for debugging issues, improving performance, etc.

[eddyb]

You might not have seen the multi-version UI, and I didn't mention these passes because they might be buggy for you, but for Rust-GPU you could try adding --spirt-passes=reduce,fuse_selects, or even:

RUSTGPU_CODEGEN_ARGS="--no-early-report-zombies --no-infer-storage-classes --spirt-passes=qptr,reduce,fuse_selects --dump-spirt-passes=$PWD/spirt-passes"

(as any of those passes might be broken, you may need to remove some of them. the --no- options are both required for qptr, as qptr isn't a single pass and doesn't support everything etc.)

In theory, the leftmost column could be source code, but if you've looked at code with a large amount of inlining, you'll see that adjacent instructions can hop between files or functions in the same file, and this is a problem I haven't seen anything like godbolt tackle (well, it can handle one file just fine, but nothing beyond that).

My best idea would be a hover box that shows a scrollable view of the entire file, with the range in the debuginfo being highlighted (but that would require a bit more active JS - still, I've been wanting things like that for a while, including for e.g. hovering on T123 and seeing its definition)

[nazar-pc]

I initially imagine something like a profiler source view, with code on the left and compiled instructions on the right, but this may not work here since the actual file we're looking at is compiled instructions, so I think it should be the other way around. Tools like cargo-show-asm and even good old perf are probably a more appropriate references, which show assembly and source code that correspond to them.

The first and already useful step would be to convert file paths and line numbers to the source code lines that correspond to them. From there additional information could be incorporated (like when there are 3 lines of SPIR-T that were compiled from 5 lines of Rust, then it should probably be shown as two blocks next to each other.

Not sure how to draw the separation of what depth to show (application code vs standard library or other dependencies for example), maybe some kind of stacktrace (forward or inverse) would be the answer here.

This rabbit hole goes very deep once you start thinking about it.

[eddyb]

I would like to see a mock of that (text or image, anything, doesn't have to be fancy), to understand it.

Because my concern is roughly that 3 adjacent SPIR-T instructions could come from 3 different functions, in 3 different files, and crossing a dozen different inlining depth levels (try making a series of #[inline(always)] functions, that each calls the next, and only the last one does a simple a + b or w/e, and you'll see what I mean).

Also, even if a group of SPIR-T instructions map to source code all in one function, there's no ordering guarantee, it could jump all over the place, only at a large scale will it advance monotonically within the source (and mainly thanks to side-effects).

If it's dynamic, based on hover or w/e, it's definitely doable, but you can't fit the original source code next to every instruction, without it being uselessly incomprehensible. _{(if by profiler you're referencing perf annotate or w/e it was called, that's IMO an UX disaster - there's a lot of plain text or even TUI, interfaces, that barely work, and it's mostly the tragedy of "anything more useful is too much effort to build")}

Not sure how to draw the separation of what depth to show (application code vs standard library or other dependencies for example), maybe some kind of stacktrace (forward or inverse) would be the answer here.

Not sure what this means, SPIR-T doesn't really understand anything other than "inlined call" debuginfo atm, and you can't really show just the call itself when talking about instructions in the callee (regardless of location).

If you look at the screenshots in the recent PR which cleaned a lot of this up:

• print: name and reuse inlined call site debuginfo "scopes". #18

You will see that the chain of "inlined call" debuginfo used to be rendered like a stacktrace, and that was the cause of massive bloat in the output (including making things generally unreadable).

I suppose that with the dynamic "show source on hover", you could also make it possible to peek at the debug scope, which give you e.g. the source code of the inline call (when looking at instructions in the callee), and maybe even let you go through all the calls all the way out back to the entry-point (although you can kind of already do that by clicking on d123 links, tbf).

---

Anyway, if you want something that dynamically adjusts its presentation based on interactions (been thinking "on hover", though clicks etc. could also make sense), that's certainly doable (not sure when I will get to it though).

Something static, like inline code snippets, or the existing multiversion (make sure to check out the examples from my previous comment, or maybe Rust-GPU/rust-gpu#332 if you can trigger one of its new errors) table layout, could certainly be less effort to set up, but my imagination fails me as to how that would even lead to anything useful (and not just looking like someone shuffled the bytes of source code into complete incomprehensibility), for the kinds of SPIR-T I've been looking at.

[LegNeato]

Related: Rust-GPU/rust-gpu#204 and Rust-GPU/rust-gpu#202