[llvm-dev] Debug Locations for Optimized Code

[Andrea Di Biagio via llvm-dev]

On Thu, Dec 15, 2016 at 3:31 PM, Hal Finkel <hfinkel at anl.gov> wrote:

>
> ------------------------------
>
> *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/pipermai
> l/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?
>

If that is correct, and we can really use the zero factor as a special
case, then that would be great!
It would solve the pgo use case (at least for hoisted/sunk instructions) at
the cost of emitting extra discriminators, and it would probably make
people happier because we would not need to remove debug locations anymore.

- Andrea


>  -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-p
> roject?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/b2494442/attachment.html>