Loss of debug information with optimization and inlining

[Sahnvour]

I have identified cases where an inlined function's instructions all end up with their debug information pointing to an invalid source.

In particular, I have a program calling a function foo that itself calls bar. bar is inlined when it is called by foo, but the PDB matches all the instructions produced by bar with the definition line of foo. Even though bar is non-trivial and should clearly be identifiable, even in optimized code. Indeed, this is a problem in Release mode.

I think this may have gone unnoticed because we usually don't use debug info much with release executables. I encountered this when trying to profile my program, and saw that every sampled instruction was matched with the function definition. The same happens when running it through a debugger.

Modifying foo to do @noInlineCall(bar, ...) fixed this and I was then able to step through bar.

@andrewrk I think this is related to the issue we discussed in #2029. Which now makes me wonder if it's a target-specific issue.

I stepped through the ir_render and ir_render_call in case I find anything suspicious, but at this point the debug info seemed correct. Maybe the issue occurs later, in a LLVM optimization pass, when instructions are merged and the wrong debug info is chosen ? For example, since in my case everything bar does is related to its parameters (themselves coming from foo), it could be that somehow the debug info from parameter declarations are kept. Just a supposition, I don't know much about LLVM.

[andrewrk]

I think the next step in this issue is to come up with a small zig test case, followed by a pure LLVM IR test case, and then filing an upstream bug report.