search for: dw_op_llvm_explicit_pointer

...new intrinsic. >> >> * On the point of handing of pointer pointing to temporary / unnamed variables (Lets call it Scope S1) >> As two proposed patches are there for bringing pointers referring to temporary / unnamed variable >> A) first patch uses (new proposed operator) DW_OP_LLVM_explicit_pointer(both in LLVM-IR and DWARF) >> B) Second patch uses artificial variable representing temporary (both in LLVM-IR and DWARF) >> https://reviews.llvm.org/D72055 [DebugInfo] Support for DW_OP_implicit_pointer (for temp references & dynamic allocations) >> If I understoo...

...describe either the first or second level pointers that get to that value) > - it sounds like any intrinsic that's special cased to deref (like > llvm.dbg.derefval) wouldn't be able to capture that, which seems like it's > overly narrow/special case, then? > > The PoC of DW_OP_LLVM_explicit_pointer does not have handling of > multilevel indirection. As of now it is so due to below reason. > > Explicit pointer handles cases when variable points to a temporary which > contains constant. Due to language standard constraints, we don't find > pointers in such cases, what we get...

...o get de-referenced value of another reference variable (AFAIK it can not be reproduced with pointers) Such cases are being addressed using new Dwarf expression DW_OP_explicit_pointer as de-referenced value can be displayed explicitly (in place). In LLVM IR, we represent it using dbg.derefval and DW_OP_LLVM_explicit_pointer operation. Both of these two branches have some common implementation to define new operations (Dwarf and IR). (D70642, D70643, D69999, D69886). First branch has additional patches (D70260, 70384, D70385, D70419). Second branch has additional patch ( D70833). Let me try to comment on points raise...

...being drawn, it doesn't sound like the right one. >> >> As in example above pointers can be of multi-level (int *, int **, int >> ***) but references remain single level (int &). >> The difference of handling both "DW_OP_implicit_pointer" and >> "DW_OP_LLVM_explicit_pointer" is not based on pointer or reference. It is >> based on how their values can be represented. >> >> A)- Use implicit_pointer, when value can be found in another DIE (it can >> be case of pointer or reference and there can be multilevel of indirection) >> B)- Use e...

...was started before introduction of new intrinsic. * On the point of handing of pointer pointing to temporary / unnamed variables (Lets call it Scope S1) As two proposed patches are there for bringing pointers referring to temporary / unnamed variable A) first patch uses (new proposed operator) DW_OP_LLVM_explicit_pointer(both in LLVM-IR and DWARF) B) Second patch uses artificial variable representing temporary (both in LLVM-IR and DWARF) https://reviews.llvm.org/D72055 [DebugInfo] Support for DW_OP_implicit_pointer (for temp references & dynamic allocations) If I understood David correctly, he wants...

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 (0x000000000040...

On Mon, Jan 13, 2020 at 9:20 AM Adrian Prantl <aprantl at apple.com> wrote: > > > > On Jan 10, 2020, at 11:36 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > > > > > On Fri, Jan 10, 2020 at 7:02 AM Jeremy Morse < > jeremy.morse.llvm at gmail.com> wrote: > >> Hi, > >> > >> On Wed, Jan 8, 2020 at 8:38 PM

> I don't have a strong opinion on representation. I can see how having a dedicated instruction to model implicit pointers would aid readability & be simpler to document/grok, but perhaps in the future we'll want to support other operations that refer to variable > DIEs. In the short term migrating to an extended dbg.value representation might take more work. Alok, wdyt? Below