[llvm-dev] Debug Locations for Optimized Code

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "Paul Robinson" <paul.robinson at sony.com>
> To: "Hal Finkel" <hfinkel at anl.gov>, "David Blaikie" <dblaikie at gmail.com>
> Cc: llvm-dev at lists.llvm.org
> Sent: Wednesday, December 7, 2016 9:39:16 AM
> Subject: RE: [llvm-dev] Debug Locations for Optimized Code
> 
> >> 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).

Is there a reason why we must only have one location for every instruction? If not, why not merge them and keep them all?

 -Hal

> 
> 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
> 
> 

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory