[PATCH] Allocate stack storage for .block_descriptor and captured self.

[Manman Ren]

On Feb 27, 2013, at 11:31 AM, John McCall wrote:

> 
> On Feb 27, 2013, at 10:12 AM, Manman Ren <mren at apple.com> wrote:
> 
>> 
>> On Feb 26, 2013, at 9:36 AM, John McCall wrote:
>> 
>>> On Feb 26, 2013, at 9:16 AM, Adrian Prantl <aprantl at apple.com> wrote:
>>>> On Feb 25, 2013, at 5:02 PM, John McCall <rjmccall at apple.com> wrote:
>>>>> On Feb 25, 2013, at 4:55 PM, Adrian Prantl <aprantl at apple.com> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130227/848ed204/attachment.html>