[llvm-dev] Debug Locations for Optimized Code

[Robinson, Paul via llvm-dev]

>> I don't know what the right, if any, solution to this is - but I
>> thought I should bring it up in case you or anyone else wanted to
>> puzzle it over & see if the competing needs/desires might need to be
>> considered.
> One thing that I recall being discussed was changing the way that we
> set the is_stmt flag in the DWARF line-table information. As I
> understand it, we currently set this flag for the first instruction in
> any sequence that is on the same line. This is, in part, why the
> debugger appears to jump around when stepping through code with
> speculated instructions, etc. If we did not do this for out-of-place
> instructions, then we might be able to keep for debugging information
> for tools while still providing a reasonable debugging experience.

When we are looking at a situation where an instruction is merely *moved*
from one place to another, retaining the source location and having a 
less naïve statement-marking tactic could help the debugging experience 
without perturbing other consumers (although one still wonders whether 
profiles will get messed up in cases where e.g. a loop invariant gets 
hoisted out of a cold loop into a hot predecessor).

When we are looking at a situation where two instructions are *merged* or
*combined* into one, and the original two instructions had different 
source locations, that's a separate problem.  In that case there is no 
single correct source location for the new instruction, and typically 
erasing the source location will give a better debugging experience (also 
a less misleading profile).

My personal opinion is that having sanitizers *rely* on debug info for 
accurate source attribution is just asking for trouble.  It happens to 
work at –O0 but cannot be considered reliable in the face of optimization.
IMO this is a fundamental design flaw; debug info is best-effort and full 
of ambiguities, as shown above. Sanitizers need a more reliable 
source-of-truth, i.e. they should encode source info into their own 
instrumentation.

--paulr