[llvm-dev] Debug Locations for Optimized Code

[Andrea Di Biagio via llvm-dev]

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.


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161215/0609d054/attachment.html>