search for: dw_op_llvm_frag

...h a value, and that value is split up (for example a i64 load expanded into two i32 loads), I would expect to see a new ISD::DBG_VALUE tracking each fragment of the input original debug variable. However, I can't see anywhere this is handled. There seems to be some support for this, through the DW_OP_LLVM_fragment DIExpression, and there is a function DIBuilder::createFragmentExpression which could be used to create an expression to track part of a variable, however these don't seem to be used much. Thanks, Ed

Currently, two patches undergoing review wish to add a new operator for LLVM's DIExpression: D70642[0], and D82363[1]. Though both of these cases use the same name, the operators have different meanings: in the former, it has the form `DW_OP_LLVM_argN` where N is in [0-7], and represents the Nth argument of the containing intrinsic; its purpose is to enable the intrinsic @llvm.dbg.derefval,

...that if > the source variable is split up into multiple fragments (such as SROA) > there may be one dbg.declare per variable fragment. How about this: %b.sroa.4.i = alloca [32 x i32] call void @llvm.dbg.declare(metadata [32 x i32]* %b.sroa.4.i, metadata !10, metadata !DIExpression(DW_OP_LLVM_fragment, 32, 1024)), !dbg !18 call void @llvm.dbg.declare(metadata [32 x i32]* %b.sroa.4.i, metadata !10, metadata !DIExpression(DW_OP_LLVM_fragment, 32, 1024)), !dbg !20 The dbg.declares are identical except that !18 and !20 have different inlinedAt fields. The above is the result of the alloc...

...of cases the answer will be "no", but it's hard to be sure exactly what cases may open up over time. Although... > Finally, to completely derail this discussion — once we have multi-arg support, we may be able to simplify parts of the debug intrinsic handling by combining multiple DW_OP_LLVM_fragment intrinsics describing the same variable into one multi-argument expression with multiple DW_OP_LLVM_fragments. This makes for a good example of how a future change might require us to support more arguments in an intrinsic than initially seems necessary.

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

> On Sep 19, 2017, at 8:44 AM, Reid Kleckner <rnk at google.com> wrote: > > On Tue, Sep 19, 2017 at 8:40 AM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Later loop unroll comes and unrolls the loop and then suddenly we have two absolutely identical dbg.declares and the assert in addFragmentOffset() blows.

> 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

...are really bothered by the storage size, we can address this separately. > > thanks, > adrian > > > > >> Finally, to completely derail this discussion — once we have multi-arg support, we may be able to simplify parts of the debug intrinsic handling by combining multiple DW_OP_LLVM_fragment intrinsics describing the same variable into one multi-argument expression with multiple DW_OP_LLVM_fragments. > > > > This makes for a good example of how a future change might require us to support more arguments in an intrinsic than initially seems necessary. > > __________...

...ress this separately. > >> > >> thanks, > >> adrian > >> > >>> > >>>> Finally, to completely derail this discussion — once we have multi-arg support, we may be able to simplify parts of the debug intrinsic handling by combining multiple DW_OP_LLVM_fragment intrinsics describing the same variable into one multi-argument expression with multiple DW_OP_LLVM_fragments. > >>> > >>> This makes for a good example of how a future change might require us to support more arguments in an intrinsic than initially seems necessary. >...

Thank You for suggestion Adrian! Generated reproducer for the crash using clang reproducer and CReduce. ::Attachment:: C file. NIT: some clean up is done on this file just to silent some compiler warnings(like implicit declaration etc.) Crash can be reproduced using above test case with following commandline: $clang -g -O3 -mllvm –enable-partial-inlining creducegenerated-cleaned.c -c ---CRASH---

...match multiple DBG_VALUE's if there happen to be multiple variables described by a single vreg. The apply step's DBG_VALUE creates DBG_VALUEs corresponding to each of those that were matched. createDIExprLLVMFragment invokes C++ code which creates a new DIExpression by concatenating a 'DW_OP_LLVM_fragment, 0, sizeof(type)' for the given type to the existing DIExpression. One interesting benefit of this is that it allows us to verify that all DILocations and DBG_VALUE's are accounted for and handled in some way. I should mention that I'm not terribly keen on the current syntax for m...