On Feb 27, 2013, at 11:31 AM, John McCall wrote:
>
> On Feb 27, 2013, at 10:12 AM, Manman Ren <[email protected]> wrote:
>
>>
>> On Feb 26, 2013, at 9:36 AM, John McCall wrote:
>>
>>> On Feb 26, 2013, at 9:16 AM, Adrian Prantl <[email protected]> wrote:
>>>> On Feb 25, 2013, at 5:02 PM, John McCall <[email protected]> wrote:
>>>>> On Feb 25, 2013, at 4:55 PM, Adrian Prantl <[email protected]> wrote:
>>>>>> here’s another patch for review:
>>>>>>
>>>>>> Allocate stack storage for .block_descriptor and captured self.
>>>>>> This way the register allocator will not optimize away the the
>>>>>> debug info for captured variables.
>>>>>
>>>>> Allocating stack storage is not the right way to fix this problem.
>>>>> The frontend is emitting the right intrinsics to say that the argument
>>>>> is being kept in an LLVM value, not in memory. If that's not working,
>>>>> then basically all optimized debug info is useless.
>>>>
>>>> Just to provide you with more details: The problem manifested itself even
>>>> at -O0 because the DebugValue would be kicked out by RegAllocFast.cpp:855
>>>> under high register pressure (I think). Is there another, better way to
>>>> force the DebugValue to survive register allocation?
>>>
>>> Is the value being lost completely (because it's no longer live), or is it
>>> just being moved between registers or spilled? Because it seems to me that
>>> it's a perfectly reasonable request to make of register allocation that it
>>> not drop debug info for live values.
>> Here is what happened in the backend:
>> %vreg23<def> = COPY %vreg5;
>> %vreg22<def, tied 1> = ADD64ri32 %vreg23<tied0> …
>> DBG_VALUE %vreg23, 0, !"self"
>>
>> The last usage of %vreg23 is in DBG_VALUE. When processing ADD64ri32, since
>> %vreg23 was only used in DBG_VALUE afterwards, its content was not spilled
>> to stack.
>> At DBG_VALUE, %vreg23 is lost, it is not in a physical register, nor in a
>> spill slot. And we will see error message "Unable to allocate vreg used by
>> DBG_VALUE".
>
> Okay, you're saying that the value is actually no longer live at all at this
> point in the function? It seems reasonable to lose track of the debug info
> then, although we should be leaving behind a marker in the DWARF that says
> the value is unavailable.
A little more details:
The related LLVM IR looks like:
define internal void @"__39-_block_invoke_2"(i8* %.block_descriptor, i8*
%object, %7* %change2, i8* %stopObserving2) uwtable ssp {
entry:
...
call void @llvm.dbg.value(metadata !{i8* %.block_descriptor}, i64 0, metadata
!3846), !dbg !3856
…
%block = bitcast i8* %.block_descriptor to <{ i8*, i32, i32, i8*,
%struct.__block_descriptor*, %2* }>*, !dbg !3856
%block.captured-self = getelementptr inbounds <{ i8*, i32, i32, i8*,
%struct.__block_descriptor*, %2* }>* %block, i32 0, i32 5, !dbg !3856
call void @llvm.dbg.declare(metadata !{<{ i8*, i32, i32, i8*,
%struct.__block_descriptor*, %2* }>* %block}, metadata !3860), !dbg !3861
…
}
%block is associated with !3860, which is variable self, %block is not used
after dbg.declare, but block.captured-self is used afterwards.
bitcast is converted to COPY, getelementptr is converted to ADD64ri32, and
dgb.declare is converted to DBG_VALUE.
Yes, %block (%vreg23) is no longer live after dbg.declare(DGB_VALUE).
Thanks,
Manman
>
> If we want to make stronger guarantees in -O0 for purposes of debugging — and
> I think that's reasonable — then throwing the value in an alloca is
> acceptable.
>
> John.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
