<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Andrea Di Biagio" <andrea.dibiagio@gmail.com><br><b>To: </b>"Paul Robinson" <paul.robinson@sony.com><br><b>Cc: </b>"Hal Finkel" <hfinkel@anl.gov>, "David Blaikie" <dblaikie@gmail.com>, llvm-dev@lists.llvm.org<br><b>Sent: </b>Thursday, December 15, 2016 9:05:00 AM<br><b>Subject: </b>Re: [llvm-dev] Debug Locations for Optimized Code<br><br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 7, 2016 at 3:39 PM, Robinson, Paul via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><span>>> I don't know what the right, if any, solution to this is - but I<br>
>> thought I should bring it up in case you or anyone else wanted to<br>
>> puzzle it over & see if the competing needs/desires might need to be<br>
>> considered.<br>
> One thing that I recall being discussed was changing the way that we<br>
> set the is_stmt flag in the DWARF line-table information. As I<br>
> understand it, we currently set this flag for the first instruction in<br>
> any sequence that is on the same line. This is, in part, why the<br>
> debugger appears to jump around when stepping through code with<br>
> speculated instructions, etc. If we did not do this for out-of-place<br>
> instructions, then we might be able to keep for debugging information<br>
> for tools while still providing a reasonable debugging experience.<br>
<br>
</span>When we are looking at a situation where an instruction is merely *moved*<br>
from one place to another, retaining the source location and having a<br>
less naïve statement-marking tactic could help the debugging experience<br>
without perturbing other consumers (although one still wonders whether<br>
profiles will get messed up in cases where e.g. a loop invariant gets<br>
hoisted out of a cold loop into a hot predecessor).<br></blockquote><div><br></div><div>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.<br></div><div>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: <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-October/106532.html" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2016-October/106532.html</a>.<br></div><div id="DWT63457"><br></div></div></div></div></blockquote>I think that you could use that scheme: just encode a duplication factor of zero. Dehao, is that correct?<br><br> -Hal<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
When we are looking at a situation where two instructions are *merged* or<br>
*combined* into one, and the original two instructions had different<br>
source locations, that's a separate problem. In that case there is no<br>
single correct source location for the new instruction, and typically<br>
erasing the source location will give a better debugging experience (also<br>
a less misleading profile).<br></blockquote><div> <br></div><div>For the record: revision 289661 (<a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=289661" target="_blank">http://llvm.org/viewvc/llvm-project?view=revision&revision=289661</a>) 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.<br><br><br></div><div>-Andrea</div><div><br></div></div></div></div>
</blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Lead, Compiler Technology and Programming Languages<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>