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

[Eric Christopher]

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

>
> On Feb 12, 2013, at 7:32 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>
> wrote:
>
>
> On Feb 12, 2013, at 7:20 PM, Eric Christopher <echristo at gmail.com> wrote:
>
>
>
> 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.
>
>
> I think that the alloca is required at -O0, otherwise we could lose track
> of an argument value. Suppose code like this:
>
> void f(int a) {
>   int b = a+1;
>   // do stuff with b, ignore a.
>   // break here, print a.
> }
>
> If a is passed to the function in r0, there is a good chance the fast
> register allocator will reuse that register, and we would lose track of a.
> Storing a in an alloca is the only way of making the value available to the
> debugger in the whole function.
>
>
> To elaborate a bit, we only provide a 'best effort' service for
> llvm.dbg.value intrinsics, even at -O0.
>
> Ideally, at any program point dominated by the intrinsic, we'll point the
> debugger at the specified value if it exists anywhere. But we can't
> (reasonably) guarantee that the value is available in a register or on the
> stack throughout the whole function.
>
>
Agreed.


> That is easier with llvm.dbg.declare. As long as we don't reuse alloca
> stack space, we can simply point the debugger at the stack slot used for
> the alloca.
>

Right. Though what I was thinking was more like this out of the front end:

define void @f(i32 %a) {
entry:
  %a.addr = alloca i32, align 4
  %b = alloca i32, align 4
  call void @llvm.dbg.declare(metadata !{i32 %a}, metadata !8), !dbg !9
  call void @llvm.dbg.declare(metadata !{i32* %b}, metadata !10), !dbg !11
  store i32 %a, i32* %a.addr, align 4
  call void @llvm.dbg.value(metadata !{i32* %a.addr}, 0, metadata !8), !dbg
!9
  %0 = load i32* %a.addr, align 4, !dbg !11
  %add = add nsw i32 %0, 1, !dbg !11
  store i32 %add, i32* %b, align 4, !dbg !11

...

}

and then we could use the live variables (or some sort of var tracking
code) to keep the locations that we have up to date. Basically emitting the
alloca gives us a place it was likely spilled on entry and then we can get
that back - if we weren't too smart during fast-isel which seems to be
getting smarter over the years. Mostly my concern is that I'd like to see
the entries start from the incoming argument and then proceed to the alloca
rather than start after the alloca is initialized.

Something similar to what we're doing for the byval here (from the PR I
mentioned above, slightly modified since it uses a dbg.declare):

%struct.foo = type { i64, i64, i64, i64 }

define void @_Z4func3fooi(%struct.foo* align 8 byval %f, i32 %i) nounwind
ssp uwtable {
entry:
  %i.addr = alloca i32, align 4
  call void @llvm.dbg.value(metadata !{%struct.foo* %f}, i64 0, metadata
!15), !dbg !16
  store i32 %i, i32* %i.addr, align 4
  call void @llvm.dbg.declare(metadata !{i32* %i.addr}, metadata !17), !dbg
!16
  ret void, !dbg !18
}

except not actually losing the value for f. And yes, I agree, if we could
change the generated code we could be sure to store to the stack slot.
Mostly, I guess, I'm less concerned with making sure that the value is live
through the entire block as making it easier and more reliable to get the
initial values/locations and if it goes out of range then the debugger
usually keeps the incoming value anyhow.

Hrm. I guess I'm less convinced now than I was, but scanning through the
code to find whether or not we have an argument seems broken. Maybe
dbg.declares for arguments, values for the updates including a new alloca?
Could lead to slightly better O0 code (and probably faster compiles) if we
omit the alloca, but if we know we've got the original value stored into a
stack slot we can use overlapping address ranges in the location lists to
make sure we've always got the stack value around to use. This way we could
also get rid of the (very) odd list of function variables that we emit when
we're not at O0 in the metadata for the subprogram.

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