> On Mar 30, 2020, at 4:13 AM, Jeremy Morse via llvm-dev <llvm-dev at lists.llvm.org> 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.Correct, you should not be mixing dbg.declare and other instrinsics for the same variable. See also https://llvm.org/docs/SourceLevelDebugging.html#llvm-dbg-declare <https://llvm.org/docs/SourceLevelDebugging.html#llvm-dbg-declare> -- adrian> > 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. > > [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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200330/964d6039/attachment-0001.html>
Sourabh Singh Tomar via llvm-dev
2020-Mar-31 06:57 UTC
[llvm-dev] Question WRT llvm.dbg.value
> My understanding is that this isn't correct: dbg.declare specifies thememory 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. > Correct, you should not be mixing dbg.declare and other instrinsics for the same variable How about patching up llvm for the same, currently the IR showed above is valid and can be processed by llvm for target code generation. Should we move ahead invalidate this behavior as in "declare and value intrinsic can't be specified for same local variable". ? So that no FE should generate this sort of thing in first place. clang doesn't do that so this change should not affect clang. Thanks, Sourabh. On Tue, Mar 31, 2020 at 2:24 AM Adrian Prantl <aprantl at apple.com> wrote:> > > On Mar 30, 2020, at 4:13 AM, Jeremy Morse via llvm-dev < > llvm-dev at lists.llvm.org> 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. > > > Correct, you should not be mixing dbg.declare and other instrinsics for > the same variable. > > See also https://llvm.org/docs/SourceLevelDebugging.html#llvm-dbg-declare > > -- adrian > > > 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. > > [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 > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200331/a0717ec6/attachment-0001.html>
Hi! On Tue, 2020-03-31 at 12:27 +0530, Sourabh Singh Tomar via llvm-dev wrote:> > 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. > > > > Correct, you should not be mixing dbg.declare and other > instrinsics for the same variable > > How about patching up llvm for the same, currently the IR showed above is > valid and can be processed by llvm for target code generation. > Should we move ahead invalidate this behavior as in "declare and value > intrinsic can't be specified for same local variable". ?Do you mean documenting the desired frontend behavior, or adding some verifier in LLVM? A warning for the latter is that SROA may currently emit IR that contains a mix of declares and values for different fragments of an aggregate variable, so I assume that is something that would need to be fixed then. Here is a ticket for that: https://bugs.llvm.org/show_bug.cgi?id=39314 In that case LLVM incorrectly emits a single location description using the information from the declares, and ignores the values, which would have produced a location list. Best regards, David> So that no FE should generate this sort of thing in first place. clang > doesn't do that so this change should not affect clang. > > Thanks, > Sourabh.
> On Mar 30, 2020, at 11:57 PM, Sourabh Singh Tomar <sourav0311 at gmail.com> wrote: > >> > 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. > > > Correct, you should not be mixing dbg.declare and other instrinsics for the same variable > > How about patching up llvm for the same, currently the IR showed above is valid and can be processed by llvm for target code generation. > Should we move ahead invalidate this behavior as in "declare and value intrinsic can't be specified for same local variable". ? > > So that no FE should generate this sort of thing in first place. clang doesn't do that so this change should not affect clang.Adding this to the Verifier sounds like a good idea to me. It may be possible that this uncovers existing bugs in the current flow, but that would be a good thing. -- adrian