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

[Jakob Stoklund Olesen]

On Feb 12, 2013, at 9:32 PM, Eric Christopher <echristo at gmail.com> wrote:

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

I think that would make sense, and if it could help clean up some of the special handling of arguments, that would be great.

A dbg.value on the formal argument should be safe as long as there is a dbg.declare one the argument has been written to the alloca.

[...]

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

I think it would be difficult to get rid of the alloca. Also remember that the fast register allocator doesn't do cross-block liveness, so it would spill the argument anyway in a function with multiple blocks.

/jakob