search for: dw_op_llvm_fragment

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

...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 by *d...

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

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