<div dir="ltr"><div>Let me try to summarize the implementation first.</div><div><br></div><div>At the moment, there are two branches.</div><div><br></div><div>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.</div><div> 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.<br></div><div><br></div><div>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)</div><div> 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.</div><div><br></div><div>Both of these two branches have some common implementation to define new operations (Dwarf and IR). (D70642, D70643, D69999, D69886). <br></div><div>First branch has additional patches (D70260, 70384, D70385, D70419).</div><div>Second branch has additional patch (
D70833).</div><div><br></div><div>Let me try to comment on points raised by you.</div><div>- Branch 2, (patch D70833) handles cases when temporaries (not existing variables) are optimized out.<br></div><div>- In patch D70385, I have included test points to display that multi layered pointers are working (llvm/test/DebugInfo/dwarfdump-implicit_pointer_mem2reg.c).</div><div><br></div><div>I feel that review of branch 1 (implicit pointer) can be resumed (which was halted due to current discussion), while we can continue to discuss branch 2 (explicit pointers
D7083) if you want. David, what do you think?</div><div><br></div><div>Regards,</div><div>Alok<br>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 29, 2019 at 4:40 AM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Sorry I haven't been more engaged with this thread, I have been reading it, so hopefully my reply isn't completely out of line/irrelevant - but I still feel like having a custom dwarf expression operator (& no new intrinsics), like we have for one or two other DW_OP_LLVM_* (that aren't actually generated into the DWARF - though this one perhaps could be in some/all cases as an extension, maybe - or a synthesized variable could be created for compatibility with the current DWARF standard) would make the most sense.<br><br>Some thought experiments that I think are relevant:<br>* does the proposed IR format scale to pointers that don't point to existing variables (that I think has already been touched on in this thread)<br>* does the proposed 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?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 28, 2019 at 2:29 PM Alok Sharma via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi folks,</div><div><br></div><div>I am pushing a PoC patch <a href="https://reviews.llvm.org/D70833" target="_blank">https://reviews.llvm.org/D70833</a> for review which includes the case when temporary is promoted.</div><div><br></div><div>For such cases it generates IR as <br></div><div><br></div><div> call void @llvm.dbg.derefval(metadata i32 3, metadata !25, metadata !DIExpression(DW_OP_LLVM_explicit_pointer, DW_OP_LLVM_arg0)), !dbg !32</div><div><br></div><div>And llvm-darfdump output looks like <br></div><div><br></div><div>------------- <br></div><div>0x0000007b: DW_TAG_inlined_subroutine<br> DW_AT_abstract_origin (0x0000004f "_Z4sinkRKi")<br> DW_AT_low_pc (0x00000000004004c6)<br> DW_AT_high_pc (0x00000000004004d0)<br> DW_AT_call_file ("/home/alok/openllvm/llvm-project_derefval/build.d/david.cc")<br> DW_AT_call_line (10)<br> DW_AT_call_column (0x03)<br><br>0x00000088: DW_TAG_formal_parameter<br> DW_AT_location (indexed (0x0) loclist = 0x00000010:<br> [0x00000000004004c6, 0x00000000004004d4): DW_OP_explicit_pointer, DW_OP_lit3)<br> DW_AT_abstract_origin (0x00000055 "p")</div><div>------------ <br></div><div><br></div><div>Please note that
DW_OP_explicit_pointer denotes that following value represents de-referenced value of optimized out pointer. With necessary changes in LLDB debugger this dwarf info can help to detect the explicit de-referenced value of 'p'.</div><div><br></div><div>Hi David,</div><div><br></div><div>Should we
keep on working for the above case separately and
resume the review of implicit pointer independently now, which is updated with many suggestions from this discussion?</div><div><br></div><div>Regards,</div><div>Alok<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 20, 2019 at 11:24 PM Jeremy Morse <<a href="mailto:jeremy.morse.llvm@gmail.com" target="_blank">jeremy.morse.llvm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
For a new way of representing things,<br>
<br>
Adrian wrote:<br>
> llvm.dbg.value_new(DILocalVariable("y"), DIExpression(DW_OP_LLVM_arg0, DW_OP_LLVM_arg1, DW_OP_plus),<br>
> %ptr, %ofs)<br>
<br>
I think this would be great -- there're definitely some constructs<br>
created by the induction-variables pass and similar where one could<br>
recover an implicit variable value, if you could for example subtract<br>
one pointer from another.<br>
<br>
With the current model of storing DIExpressions as a vector of<br>
opcodes, it might become a pain to salvage a Value that gets optimised<br>
out --in the example, if %ofs were salvaged, presumably<br>
DW_OP_LLVM_arg1 could have to be replaced with several extra<br>
operations. This isn't insurmountable, but I've repeatedly shied away<br>
from scanning through DIExpressions to patch them up. A vector of<br>
opcodes is the final output of the compiler, IMHO richer metadata<br>
should be used in the meantime.<br>
<br>
IMHO the implicit pointer work doesn't need to block on this. As said<br>
my mild preference would be for a new intrinsic for this form of<br>
variable location.<br>
<br>
~<br>
<br>
Inre PR37682,<br>
<br>
> 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 source example.<br>
<br>
This has been working through my mind too, and I think it's slightly<br>
different to what implicit_pointer is trying to achieve. In the case<br>
implicit_pointer is designed for, it's a strict improvement in debug<br>
experience because you're recovering information that couldn't be<br>
expressed. However for PR37682 it's a trade-off between whether the<br>
user might want to examine the pointer, or the pointed-at integer:<br>
AFAIUI, we can only express one of the two, not both. Wheras for<br>
mem2reg'd variables referred to by DIE, there is never a pointer to be<br>
lost.<br>
<br>
I think my preference would always be to see temporarily-promoted<br>
values as there's no other way of observing them, but others might<br>
disagree.<br>
<br>
--<br>
Thanks,<br>
Jeremy<br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>