<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 5, 2014 at 5:55 PM, Alexey Samsonov <span dir="ltr"><<a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote"><div class="">On Wed, Jun 4, 2014 at 5:18 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I do rather feel this perhaps rises beyond my idea comfort level for "work around" to "we should probably fix this the right way", but I realize I'll probably be argued down on this.<br>


<br>
Out of curiosity, does anyone happen to be able to explain LiveDebugVariables.cpp:956-966. It /looks/ like this code, based on the comment, is trying to do what we want: add dbg.value intrinsics to every basic block for which the variable is live. Any idea if this works? Why it doesn't? etc...<br>

</blockquote><div><br></div></div><div>This code doesn't work because the whole LiveDebugVariables pass is run only in greedy register allocator, while we use a fast register allocator in -O0 mode. From a brief examination, it seems</div>

<div>that -livedebug pass is somewhat tied to greedy regalloc implementation, and we can't simply flip the flag and "enable" it unconditionally. However, we should go along this path:</div><div>apparently we need this kind of analysis on all opt levels.</div>

<div><br></div><div>I'd feel more comfortable to work on these passes, having suggested workaround applied, though.</div></div></div></div></blockquote><div><br></div><div>In fact, I'm now going to apply this patch that would hopefully put us in less fire-fighting position.</div>
<div>I've considered an alternative of whitelisting the set of registers which are believed not to change in the function in the real-world, but we at least need</div><div>both frame register and stack register in this set, while generic TargetRegisterInfo gives us only the former. Extending this interface and modifying a number</div>
<div>of backends is a more intrusive change.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
<a href="http://reviews.llvm.org/D3933" target="_blank">http://reviews.llvm.org/D3933</a><br>
<br>
<br><span class="HOEnZb"><font color="#888888">
</font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div>
</div></div>