search for: dw_op_llvm_arg0

...on in the instruction stream. That first SSA value argument is an implicit first element in the DIExpression. A more general form would be a more printf-like signature: llvm.dbg.value(DILocalVariable, DIExpression, ...) for example llvm.dbg.value_new(DILocalVariable("x"), DIExpression(DW_OP_LLVM_arg0), %x) llvm.dbg.value_new(DILocalVariable("y"), DIExpression(DW_OP_LLVM_arg0, DW_OP_LLVM_arg1, DW_OP_plus), %ptr, %ofs) llvm.dbg.value_new(DILocalVariable("z"), DIExpression(DW_OP_implicit_pointer, DW_OP_LLVM_arg0, 32), DILocalVariable("...

...clude that in LLVM IR, because representation and specification (types of operands) of it a bit different that actual dwarf expression DW_OP_LLVM_implicit_pointer. while creating actual dwarf info it will be converted to DW_OP_LLVM_implicit_pointer. This is implemented and patch is updated for it. DW_OP_LLVM_arg0 * This is good suggestion and will help in readability. It is also implemented and is available in updated patch. Splitting dbg.value * This is also a good idea from readability point of view. It also opens possibility of extension below is explanation. Since dbg.value currently represents (VA...

Hi folks, I am pushing a PoC patch https://reviews.llvm.org/D70833 for review which includes the case when temporary is promoted. For such cases it generates IR as call void @llvm.dbg.derefval(metadata i32 3, metadata !25, metadata !DIExpression(DW_OP_LLVM_explicit_pointer, DW_OP_LLVM_arg0)), !dbg !32 And llvm-darfdump output looks like ------------- 0x0000007b: DW_TAG_inlined_subroutine DW_AT_abstract_origin (0x0000004f "_Z4sinkRKi") DW_AT_low_pc (0x00000000004004c6) DW_AT_high_pc (0x00000000004004d0)...

Hey folks, Would you all mind having a bit of a design discussion around the feature both at the DWARF level and the LLVM implementation? It seems like what's currently being proposed/reviewed (based on the DWARF feature as spec'd) is a pretty big change & I'm not sure I understand the motivation, exactly. The core point of my confusion: Why does describing the thing a pointer

...gt;>>> which includes the case when temporary is promoted. >>>> >>>> For such cases it generates IR as >>>> >>>> call void @llvm.dbg.derefval(metadata i32 3, metadata !25, metadata >>>> !DIExpression(DW_OP_LLVM_explicit_pointer, DW_OP_LLVM_arg0)), !dbg !32 >>>> >>>> And llvm-darfdump output looks like >>>> >>>> ------------- >>>> 0x0000007b: DW_TAG_inlined_subroutine >>>> DW_AT_abstract_origin (0x0000004f "_Z4sinkRKi") >>>>...

...tch https://reviews.llvm.org/D70833 for review >> which includes the case when temporary is promoted. >> >> For such cases it generates IR as >> >> call void @llvm.dbg.derefval(metadata i32 3, metadata !25, metadata >> !DIExpression(DW_OP_LLVM_explicit_pointer, DW_OP_LLVM_arg0)), !dbg !32 >> >> And llvm-darfdump output looks like >> >> ------------- >> 0x0000007b: DW_TAG_inlined_subroutine >> DW_AT_abstract_origin (0x0000004f "_Z4sinkRKi") >> DW_AT_low_pc (0x00000000004004c6) &gt...

...lue from the entire containing intrinsic. My personal opinion (possibly biased as the author of D82363) is that the best solution is to remove DW_OP_LLVM_argN from the implicit pointer work altogether. The operator introduced in that patch is more general-purpose than necessary; it is only used as DW_OP_LLVM_arg0 and in conjunction with @llvm.dbg.derefval, an intrinsic added in that patch. It seems at a glance that the functionality could be folded into the new intrinsic and operator pair by having them automatically refer to arg0. While it's possible that this general-purpose operator could have value...

...> >>>>>>>>> For such cases it generates IR as >>>>>>>>> >>>>>>>>> call void @llvm.dbg.derefval(metadata i32 3, metadata !25, >>>>>>>>> metadata !DIExpression(DW_OP_LLVM_explicit_pointer, DW_OP_LLVM_arg0)), !dbg >>>>>>>>> !32 >>>>>>>>> >>>>>>>>> And llvm-darfdump output looks like >>>>>>>>> >>>>>>>>> ------------- >>>>>>>>> 0x0000007b:...