[llvm-dev] Question WRT llvm.dbg.value

David Stenberg via llvm-dev llvm-dev at lists.llvm.org
Mon Mar 30 07:38:44 PDT 2020


Hi!

On Mon, 2020-03-30 at 12:13 +0100, Jeremy Morse via llvm-dev wrote:
> Hi Sourabh,
> 
> On Mon, Mar 30, 2020 at 8:09 AM Sourabh Singh Tomar via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Under what circumstances should a frontend choose to emit(at -O0(No
> > optimization)) llvm.dbg.value for a local variable.
> > 
> > I saw some debuginfo code in flang(older one), sort of it choose to emit
> > *llvm.dbg.value* for *every load operation* happening on a *local variable*.
> > And as noted below in IR snippet it has already emitted *llvm.dbg.declare*
> > for the local variable.
> 
> [...]
> 
> >  call void @llvm.dbg.declare(metadata i32* %foo, metadata !9, metadata
> > !DIExpression()), !dbg !11
> > %0 = load i32, i32* %foo, align 4, !dbg !13
> >   call void @llvm.dbg.value(metadata i32 %0, metadata !9, metadata
> > !DIExpression()), !dbg !11
> 
> My understanding is that this isn't correct: dbg.declare specifies the
> memory address of a variable for the whole lifetime of the function,
> whereas dbg.value (and dbg.addr) specify the value/address until the
> next debug intrinsic. Mixing these two kinds of intrinsics creates
> ambiguity over where the variable location is at different positions
> in the code.
> 
> If dbg.value intrinsics are to be used and the variable can be located
> in memory too, then the producer needs to specify where the location
> switches from a value to an address (and vice versa) with dbg.value /
> dbg.addr. Awkwardly,I think there are some issues with dbg.addr at -O0
> that Brian ran into here [0, 1], which might need addressing.

There are also some issues with how SelectionDAG place the resulting DBG_VALUE
instructions for dbg.addr: https://bugs.llvm.org/show_bug.cgi?id=35318

Best regards,
David

> [0] http://lists.llvm.org/pipermail/llvm-dev/2020-February/139500.html
> [1] http://lists.llvm.org/pipermail/llvm-dev/2020-February/139511.html
> 
> --
> Thanks,
> Jeremy
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


More information about the llvm-dev mailing list