<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 2, 2014 at 5:01 PM, Robinson, Paul <span dir="ltr"><<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">> -----Original Message-----<br>
> From: <a href="mailto:llvm-commits-bounces@cs.uiuc.edu">llvm-commits-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvm-commits-">llvm-commits-</a><br>
> <a href="mailto:bounces@cs.uiuc.edu">bounces@cs.uiuc.edu</a>] On Behalf Of Alexey Samsonov<br>
><br>
> Hi dblaikie,<br>
><br>
> This change preserves the original algorithm of generating history<br>
> for user variables, but makes it more clear.<br>
><br>
> High-level description of algorithm:<br>
> Scan all the machine basic blocks and machine instructions in the order<br>
> they are emitted to the object file. Do the following:<br>
> 1) If we see a DBG_VALUE instruction, add it to the history of the<br>
> corresponding user variable. Keep track of all user variables, whose<br>
> locations are described by a register.<br>
> 2) If we see a regular instruction, look at all the registers it<br>
> clobbers,<br>
> and terminate the location range for all variables described by these<br>
> registers.<br>
> 3) At the end of the basic block, terminate location ranges for all<br>
> user variables described by some register.<br>
><br>
> (3) is too restrictive, and may result in a poor debug info.<br>
> For example, the variable location can be described by %rsp, or any<br>
> other<br>
> register which is never clobbered in a function. I think that handling<br>
> this special case may improve situation for many real-life programs and<br>
> plan to address this in future commits.<br>
<br>
</div></div>Taking no stand on the patch, just on that last statement...<br>
<br>
(3) is correctly conservative, because variable-in-register liveness<br>
depends on control flow but debug-value ranges are expressed in terms<br>
of physical order.  Getting this truly right requires a dataflow<br>
analysis to track liveness across block boundaries.<br></blockquote><div><br></div><div>Yes, I understand that solving this problem for general case, especially that late</div><div>in codegen (and assuming the MachineFunction can't be modified at this point) is... hard.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There may be special cases of small multi-block functions where some<br>
variable lives in a register that is never clobbered, but I question<br>
how often that will come up in real programs.<br>
<br>
If a variable has a "home" on the stack, that's a different story.<br>
Naively you can fall back to the stack location after a register<br>
copy is clobbered and probably 90%-95% of the time you're fine.<br></blockquote><div><br></div><div>Simple cases for variables that are stored in some stack slot work fine,</div><div>and in fact handled by different code path (they are described by MMI side-table).</div>
<div>IIRC, I have observed problems for more complex cases, where we spill address of the variable,</div><div>not the variable itself (so that accessing its value requires DW_OP_deref operation).</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

--paulr<br>
<br>
><br>
> <a href="http://reviews.llvm.org/D3597" target="_blank">http://reviews.llvm.org/D3597</a><br>
><br>
> Files:<br>
>   lib/CodeGen/AsmPrinter/DbgValueHistoryCalculator.cpp<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Alexey Samsonov, Mountain View, CA</div></div>
</div></div>