search for: dw_op_implicit_pointer

...-list Since it was just for better readability in LLVM IR only later it (new intrinsic) was sharing the same path with llvm.dbg.value. So it should be fine to drop it without any impact in later functionality. - On question of identify such cases we can anyway identify using the type of expression (DW_OP_implicit_pointer). - On question of ( DW_OP_implicit_pointer ) fitting to dbg.value intrinsic it perfectly does that as value in such case is metadata and prototype of dbg.value is dbg.value(metadata, metadata, metadata). So it should be fine to drop it and back to where it was started before introduction of new in...

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

...ursday, November 14, 2019 5:32 PM > *To:* Robinson, Paul <paul.robinson at sony.com> > *Cc:* Adrian Prantl <aprantl at apple.com>; AlokKumar.Sharma at amd.com; Jonas > Devlieghere <jdevlieghere at apple.com>; llvm-dev <llvm-dev at lists.llvm.org> > *Subject:* Re: DW_OP_implicit_pointer design/implementation in general > > > > > > > > On Thu, Nov 14, 2019 at 1:53 PM Robinson, Paul <paul.robinson at sony.com> > wrote: > > My reading of the DWARF issue is that it was fairly specifically designed > to handle the case of a function taking para...

..., maintaining a pointer to actual_obj might be sub-optimal, > but after a “step in” to inline_me, the user wants to look at an expression > spelled *ptr even though the actual_obj might not have a memory address > (because fields are SROA’d into registers, or whatever). This is where > DW_OP_implicit_pointer saves the day; *ptr and ptr->x are still evaluatable > expressions, which expressions are secretly indirecting through the DIE for > actual_obj. > > > > I think it is not widely applicable outside of that kind of scenario. > Any ideas why it wouldn't be more general to...

...cs where their position in the IR is important, from > * Debug intrinsics where both their position in the IR, _and_ a Value > in the IR, are important. > Of which (I think) implicit pointers are the former, and current [2] > dbg.values are the latter. This would also avoid putting > DW_OP_implicit_pointer into expressions in the IR, pre-isel at least. > On that particular point, I would like to see is a generalization of dbg.value: Currently llvm.dbg.value binds an SSA value (including constants and undef) and a DIExpression to a DILocalVariable at a position in the instruction stream. That fi...

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

...ction potentially (to use frame-relative, etc). I could think of other ways to do that in hindsight (like putting the array type definition inside the function to begin with & having the count describe the location directly, for instance). > In retrospect I find the entire specification of DW_OP_implicit_pointer to > be strangely specific/limited (why one hard-coded offset instead of an > arbitrary expression?), but that ship has sailed for DWARF 5 and I'm to > blame for not voicing that concern earlier. > Sure, but we don't have to implement it if we don't find it to be super usef...

Hi David, Happy new year ! I just uploaded a POC patch that covers the cases when pointer points to un-named variables using DW_OP_implicit_pointer (references and dynamic allocation). This is using artificial variable as suggested by Paul. https://reviews.llvm.org/D72055 I hope that now it should address your concerns. Scope of DW_OP_implicit_pointer: As we initially decided split of original patch should be splits for back-end changes + s...

...ce it was just for better readability in LLVM IR only later it (new intrinsic) was sharing the same path with llvm.dbg.value. So it should be fine to drop it without any impact in later functionality. >> - On question of identify such cases we can anyway identify using the type of expression (DW_OP_implicit_pointer). >> - On question of ( DW_OP_implicit_pointer ) fitting to dbg.value intrinsic it perfectly does that as value in such case is metadata and prototype of dbg.value is dbg.value(metadata, metadata, metadata). >> So it should be fine to drop it and back to where it was started before intr...

Let me try to summarize the implementation first. At the moment, there are two branches. 1. When an existing variable is optimized out and that variable is used to get 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...

...t, from > >> * Debug intrinsics where both their position in the IR, _and_ a Value > >> in the IR, are important. > >> Of which (I think) implicit pointers are the former, and current [2] > >> dbg.values are the latter. This would also avoid putting > >> DW_OP_implicit_pointer into expressions in the IR, pre-isel at least. > >> > > > > > > On that particular point, I would like to see is a generalization of > dbg.value: Currently llvm.dbg.value binds an SSA value (including constants > and undef) and a DIExpression to a DILocalVariable at...

> On Jan 2, 2020, at 6:37 AM, Jeremy Morse <jeremy.morse.llvm at gmail.com> wrote: > > Hi all, > > On the topic of intrinsics, right now we have two (dbg.value / > dbg.addr) that respectively describe: > * The "direct value" (quoting langref) of a variable, and > * The address of where the current variable value is stored. > Both of which map onto dwarf

...> > I’ve been reminded of PR37682, where a function with a reference > parameter might spend all its time computing the “referenced” value in a > temp, and only move the final value back to the referenced object at the > end. This is clearly a situation that could benefit from > DW_OP_implicit_pointer, and there is really no other-object DIE for it to > refer to. Given the current spec, the compiler would need to produce a > DW_TAG_dwarf_procedure for the parameter DIE to refer to. Appendix D > (Figure D.61) has an example of this construction, although it’s a more > contrived sour...

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 Adrian Prantl <aprantl at apple.com> wrote: > > As far as LLVM semantics are concerned, the implicit pointer doesn't > seem to be that much different from any other implicit values (such as > constants) to me. Why do you think that it

...have single level. (reference to reference is just reference > while pointer to pointer is double pointer). > Case of reference to reference, second level can be handled using > DW_OP_LLVM_explicit_pointer itself. > Case of pointer to reference, second level can be handled using > DW_OP_implicit_pointer. > > Though it would not be complex to make explicit pointer multilevel, I > avoided so due to lack of use case. Please let me know if I am missing > something. > Sorry, I couldn't understand your language related to references and pointers - I don't understand why they woul...

On Wed, Oct 9, 2019 at 11:59 AM Robinson, Paul <paul.robinson at sony.com> wrote: > Welcome Sourabh, > > > > There are many bits of DWARF-5 that haven’t been implemented. > Got a short list, by chance? > I know there is currently no big push within Sony to “fill in the > corners” for v5, as we have been more focused on quality of debug info for > optimized

...he initial DWARF 5 > work, things that might not be done include: > > Default location entry > Inline namespace attribute > Reference-qualified member functions > "auto" return type > Type/item alignment > Defaulted template parameter > Atomic type modifier > DW_OP_implicit_pointer > .debug_macro section > Typed expressions > Supplementary objects > Ah, thanks for the list - mostly I'm interested in cases where Clang's output is not valid DWARFv5 when requested - the new features DWARFv5 enables/allows but doesn't require are lower priority to me. Whi...