<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 1:12 AM, Sergey Dmitrouk <span dir="ltr"><<a href="mailto:sdmitrouk@accesssoftek.com" target="_blank">sdmitrouk@accesssoftek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Jun 08, 2015 at 03:00:42PM -0700, David Blaikie wrote:<br>
> Might be worth pinging the original thread to provide the full context or<br>
> continue the discussion there (the mailing list archives are bad at<br>
> navigating the full context since they chunk it up into monthly pages - so<br>
> I can't see any replies to that patch review email, for example).<br>
<br>
</span>The thread is not really helpful (here is its last message:<br>
<a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121001/152251.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121001/152251.html</a>).<br>
Comments in the PR describe what happened better:<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D14501&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=KMq5ssB_OAH3AKqxAhZ3kw6P6O8M1YNfv6oW0-h-8CQ&s=VVI8ersiL433Oy-_4ypU4jelfv3Pb_EKV2akOMRWu7k&e=" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=14501</a><br>
<span class=""><br>
> It's a bit problematic to continue to add workarounds on top of<br>
> workarounds - makes the code harder to maintain, etc. So there's something<br>
> to be said for considering what the "right" approach, if any, might be and<br>
> how much it would cost before we do this.<br>
<br>
</span>The response by Frédéric on this thread seems to be the most detailed<br>
source of possible solutions:<br>
<a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150518/277613.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150518/277613.html</a></blockquote><div><br>+Alexey, who's been hitting possibly related issues in code coverage tools (specifically what can happen due to this fallthrough is that an inlined debug location can appear non-inlined because the high/low/range of the inlined subroutine may end at the end of the prior basic block, but the locations leak into the proceeding basic block)<br><br>Alexey's theory is that it's always going to be possible that we have un-assigned locations (& the zero location is probably insufficient - GCC basically ignores it & treats it as a fallthrough location anyway and code coverage tools wouldn't create a terribly good story with it either, most likely). So if that's an unavoidable reality, then backpropagating locations is necessary no matter how much we improve the debug location accuracy/propagation on instruction creation.<br><br>I wonder if we end up with entirely un-located basic blocks (in which case it might be harder to find a location to propagate... )... <br><br>- David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Sergey<br>
</font></span></blockquote></div><br></div></div>