[llvm-dev] Question WRT llvm.dbg.value
Sourabh Singh Tomar via llvm-dev
llvm-dev at lists.llvm.org
Wed Apr 1 02:56:35 PDT 2020
> Do you mean documenting the desired frontend behavior, or adding some
LLVM? A warning for the latter is that SROA may currently emit IR that
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.
I had a quick look on that PR(thanks for sharing). A verifier(if
implemented) at LLVM level would invalidate this too. Would that be good ?
That brings up one other question, After SROA(like in present case) there
can be mix of *dbg.decalre* and *dbg.value* of the same variable left out.
Snippet from PR
call void @llvm.dbg.declare(metadata i64* %arr.sroa.0, metadata !15,
metadata DIExpression(DW_OP_LLVM_fragment, 0, 64)), !dbg !23
store i64 0, i64* %arr.sroa.0, align 16, !dbg !23
call void @llvm.dbg.value(metadata i64 0, metadata !15, metadata
!DIExpression(DW_OP_LLVM_fragment, 64, 64)), !dbg !23
Does this presence of *dbg.value* suggest that previous location/value
described by *dbg.declare* is invalidated from this point. ? Not I
suppose since Docs mentions *it's valid for entire lifetime*. Then why
mix the at first place ?
> 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.
As David mentioned, **documenting the desired behavior for frontend**
sounds good to me. this is based on premises that *clang* does not
emit any *dbg.value* at -O0(No opt) level, which is good(since most
assignments and variables are stack allocated, hence no need for
There are some FE (for instance flang), living out-of-tree they should
also follow these semantics correctly.
On Tue, Mar 31, 2020 at 8:33 PM Adrian Prantl <aprantl at apple.com> wrote:
> > On Mar 30, 2020, at 11:57 PM, Sourabh Singh Tomar <sourav0311 at gmail.com>
> >> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev