<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 21, 2016 at 12:29 PM, Keith Walker 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-GB" link="blue" vlink="purple">
<div>
<p class="MsoNormal">Adrian,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I am currently investigating issues where variables that one would expect to be available in a debugger are not in code that is compiled at optimisations other than –O0<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The main problem appears to be with the LiveDebugValues::join() method because it does not allow variables to be propagated into blocks unless all predecessor blocks have an Outgoing Location for that variable.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">As a simple example in the C code:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">int func2( int);<u></u><u></u></p>
<p class="MsoNormal">void func(int a) {<u></u><u></u></p>
<p class="MsoNormal"> int b = func2(10);<u></u><u></u></p>
<p class="MsoNormal"> for(int i = 1; i < a; i++) {<u></u><u></u></p>
<p class="MsoNormal"> func2(i+b);<u></u><u></u></p>
<p class="MsoNormal"> }<u></u><u></u></p>
<p class="MsoNormal">}<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">One would reasonable expect when stopped within the body of the for loop that you could access the variable b in a debugger (especially as it is actually referenced in the loop).<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Unfortunately this is often not the case. I believe that this is due to the requirement stated in the descriptive comment of LiveDebugValues::join() which states:<u></u><u></u></p>
<p class="MsoNormal"> “if the same source variable in all the predecessors of @MBB reside in the same location.”<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">In our simple example we end up with a series of blocks like
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"> BB#0 Initial-block Predecessor: <wbr> Successor: BB#2<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"> BB#1 for-body Predecessor: BB#2 Successor: BB#2<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"> BB#2 for-condition Predecessor: BB#0 BB#1 Successor: BB#1 BB#3<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"> BB#3 after-for Predecessor: BB#2 Successor :<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Now b is initially defined to be an “Outgoing Location” to BB#0, but it isn’t imported into BB#2 because it is not defined as an “Outgoing Location” for both predecessor blocks BB#0 and BB#1.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">So the outcome is that the variable b is not available in the debugging information while in BB#2 (or BB#1).<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Now changing the algorithm in LiveDebugValues::join() to include all Outgoing Locations from predecessor blocks appears to significantly improve the visibility of variables in such cases. However I am worried that doing this possibly
propagates the variables more than intended ... or maybe it is the right thing to do.</p></div></div></blockquote><div><br></div><div><br>GCC uses union of predecessor outs.</div><div><br></div><div>This looks to be trying to convert it to a lattice problem, but isn't handling of the lattice looks a little odd.</div><div><br></div><div><br></div></div></div></div>