search for: derefval

...s changes. Also, for the sake of not bloating the final DWARF we wouldn't want to actually push the args onto the stack first and then pick them, so we'd basically be treating the final DW_OP_pick operators as DW_OP_LLVM_arg either way. > By restricting their use to new intrinsics only (derefval and DBG_VALUE_VAR) we can avoid any confusion about whether argument 0 is implicitly pushed to the stack or not — in those new intrinsics, arguments always have to be referred to explicitly. Personally, I'm leaning more towards DW_OP_LLVM_argN, because of the space saving aspect. I think what...

...ression: 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, which represents implicit pointers. In the latter, it has the form `DW_OP_LLVM_arg, N`, where N >= 0, and represents the Nth value in a variadic debug value, which is being added in the same patch. Functionally these are quite similar; the main difference is that the latter picks the Nth value...

Hi, Let me consolidate what we discussed with my opinion. * On the point of new intrinsic llvm.dbg.derefval: It (new intrinsic) was more a neater way than a needed way. The whole functionality can go ahead without it and using llvm.dbg.value instead. Though I liked it (new intrinsic), since most of us are against it, it should be fine for me to drop it. This is because the transformation was like llvm.db...

...onto the stack first and then pick them, so we'd basically be treating the final DW_OP_pick operators as DW_OP_LLVM_arg either way. > > Agreed. I think everyone can agree that this operator is a useful addition. > > > > >> By restricting their use to new intrinsics only (derefval and DBG_VALUE_VAR) we can avoid any confusion about whether argument 0 is implicitly pushed to the stack or not — in those new intrinsics, arguments always have to be referred to explicitly. Personally, I'm leaning more towards DW_OP_LLVM_argN, because of the space saving aspect. > > >...

...IR format support multiple layers of dereference > (eg: int ** where we know it ultimately points to the value 3 but can't > 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 vari...

...we'd basically be treating the final DW_OP_pick operators as DW_OP_LLVM_arg either way. > >> > >> Agreed. I think everyone can agree that this operator is a useful addition. > >> > >>> > >>>> By restricting their use to new intrinsics only (derefval and DBG_VALUE_VAR) we can avoid any confusion about whether argument 0 is implicitly pushed to the stack or not — in those new intrinsics, arguments always have to be referred to explicitly. Personally, I'm leaning more towards DW_OP_LLVM_argN, because of the space saving aspect. > >>&...

...the de-refereced value, pointed to by another pointer/reference variable. Such cases are being addressed using Dwarf expression DW_OP_implicit_pointer as de-referenced value of a pointer can be seen implicitly (using another variable). Before Dwarf is dumped in LLVM IR, we represent it using dbg.derefval (which denotes derefereced value of pointer or reference) and DW_OP_LLVM_implicit_pointer operation. 2. When a temporary variable is optimized out and that variable is used to get de-referenced value of another reference variable (AFAIK it can not be reproduced with pointers) Such cases are bein...

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") D...

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

...-------- >> # llvm-dwarfdump multilevel_pointer >> 0x0000004a: DW_TAG_variable >> DW_AT_const_value (4) >> DW_AT_name ("var1") >> DW_AT_decl_file >> ("/home/alok/openllvm/llvm-project_derefval/build.d/multilevel_pointer.c") >> DW_AT_decl_line (14) >> DW_AT_type (0x00000037 "int") >> >> 0x00000053: DW_TAG_variable >> DW_AT_location (indexed (0x0) loclist = >> 0x0000...

...e <dblaikie at gmail.com> wrote: > > > > On Mon, Jan 13, 2020 at 8:49 PM Alok Sharma <aloksharma.knit at gmail.com> wrote: >> >> Hi, >> >> Let me consolidate what we discussed with my opinion. >> >> * On the point of new intrinsic llvm.dbg.derefval: >> It (new intrinsic) was more a neater way than a needed way. The whole functionality can go ahead without it and using llvm.dbg.value instead. Though I liked it (new intrinsic), since most of us are against it, it should be fine for me to drop it. >> This is because the transformatio...

> 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