[llvm] r175023 - Debug Info: LiveDebugVarible can remove DBG_VALUEs, make sure we emit them back.

[Eric Christopher]

On Tue, Feb 12, 2013 at 7:08 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:

>
> On Feb 12, 2013, at 7:01 PM, Eric Christopher <echristo at gmail.com> wrote:
>
> My idea is that we could track what location it is separately via abi and
> encode that and then any changes, but I was mostly thinking of not copying
> the incoming value into an alloca in the front end and rather having the
> dbg.value reference the function argument rather than the alloca. I'm not
> sure what changes we'd need to make in allocation to track this though
> offhand, my guess is some. The dbg.value on entry should have the function
> argument via the prologue (or we just add them as part of the prologue)
> which will have the ABI location and then any changes later would be marked
> by a dbg.value as well if we spilled or killed the argument value (in the
> case of unused arguments), but we'd be correct at the end of the prologue.
>
> Sound plausible?
>
>
> Are you thinking of -O0 code here? The LDV pass and the coalescer only run
> when optimizing.
>

Mmm.. a little of both. I agree that we need LDV (or some method) to keep
track of variables, but if we don't base the subprogram formal arguments on
collected variables and instead on the program arguments (which we can then
trace through for location information) then we don't need to worry about
whether or not our function descriptions are correct based upon whether or
not we managed to track a variable through the program.

In other words, I agree that we need to track variables and their
locations, just that we should use the arguments to the function for the
formal parameter for the dwarf subprogram die and we can track the argument
movement via dbg.values on the incoming argument rather than an alloca
created to copy it out.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130212/c7e4108c/attachment.html>