Rewrite calculateDbgValueHistory to make it (hopefully) more transparent.

[Alexey Samsonov]

On Fri, May 2, 2014 at 5:01 PM, Robinson, Paul <
Paul_Robinson at playstation.sony.com> wrote:

> > -----Original Message-----
> > From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
> > bounces at cs.uiuc.edu] On Behalf Of Alexey Samsonov
> >
> > Hi dblaikie,
> >
> > This change preserves the original algorithm of generating history
> > for user variables, but makes it more clear.
> >
> > High-level description of algorithm:
> > Scan all the machine basic blocks and machine instructions in the order
> > they are emitted to the object file. Do the following:
> > 1) If we see a DBG_VALUE instruction, add it to the history of the
> > corresponding user variable. Keep track of all user variables, whose
> > locations are described by a register.
> > 2) If we see a regular instruction, look at all the registers it
> > clobbers,
> > and terminate the location range for all variables described by these
> > registers.
> > 3) At the end of the basic block, terminate location ranges for all
> > user variables described by some register.
> >
> > (3) is too restrictive, and may result in a poor debug info.
> > For example, the variable location can be described by %rsp, or any
> > other
> > register which is never clobbered in a function. I think that handling
> > this special case may improve situation for many real-life programs and
> > plan to address this in future commits.
>
> Taking no stand on the patch, just on that last statement...
>
> (3) is correctly conservative, because variable-in-register liveness
> depends on control flow but debug-value ranges are expressed in terms
> of physical order.  Getting this truly right requires a dataflow
> analysis to track liveness across block boundaries.
>

Yes, I understand that solving this problem for general case, especially
that late
in codegen (and assuming the MachineFunction can't be modified at this
point) is... hard.


>
> There may be special cases of small multi-block functions where some
> variable lives in a register that is never clobbered, but I question
> how often that will come up in real programs.
>
> If a variable has a "home" on the stack, that's a different story.
> Naively you can fall back to the stack location after a register
> copy is clobbered and probably 90%-95% of the time you're fine.
>

Simple cases for variables that are stored in some stack slot work fine,
and in fact handled by different code path (they are described by MMI
side-table).
IIRC, I have observed problems for more complex cases, where we spill
address of the variable,
not the variable itself (so that accessing its value requires DW_OP_deref
operation).


> --paulr
>
> >
> > http://reviews.llvm.org/D3597
> >
> > Files:
> >   lib/CodeGen/AsmPrinter/DbgValueHistoryCalculator.cpp
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>



-- 
Alexey Samsonov, Mountain View, CA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140502/efb51ad1/attachment.html>