[llvm-dev] Debug Locations for Optimized Code

[Hal Finkel via llvm-dev]

----- Original Message -----

> From: "Andrea Di Biagio" <andrea.dibiagio at gmail.com>
> To: "Paul Robinson" <paul.robinson at sony.com>
> Cc: "Hal Finkel" <hfinkel at anl.gov>, "David Blaikie"
> <dblaikie at gmail.com>, llvm-dev at lists.llvm.org
> Sent: Thursday, December 15, 2016 9:05:00 AM
> Subject: Re: [llvm-dev] Debug Locations for Optimized Code

> On Wed, Dec 7, 2016 at 3:39 PM, Robinson, Paul via llvm-dev <
> llvm-dev at lists.llvm.org > wrote:

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

> It would be nice to have a way to mark the debugloc of an instruction
> which has been hoisted or sunk. Marked locations would not be
> treated as "reccomended breakpoint locations". That means, we could
> take advantage of that bit of information to decide how to emit the
> 'is_stmt' flag.

> For the purpose of sample pgo, is_stmt=0 would not be enough. So, it
> would be nice if we could encode that information within the
> discriminator. For example, we could emit a 'special' discriminator
> to notify consumers (example: autofdo) that the location should not
> be used for the purpose of pgo. This is obviously just an idea; not
> sure whether it makes sense, nor if it would negatively affect this
> RFC:
> http://lists.llvm.org/pipermail/llvm-dev/2016-October/106532.html .

I think that you could use that scheme: just encode a duplication factor of zero. Dehao, is that correct? 

-Hal 

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

> For the record: revision 289661 (
> http://llvm.org/viewvc/llvm-project?view=revision&revision=289661 )
> added a new API to obtain a merged/combined location from multiple
> source locations. That said, the new functionality added at that
> revision is just a stub. So, it is still unclear at the moment how
> we could 'use' that in future.

> -Andrea

-- 

Hal Finkel 
Lead, Compiler Technology and Programming Languages 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161215/790fc35e/attachment.html>