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".

Thanks,
Manman
> 
> John.
> _______________________________________________
> cfe-commits mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to