<div dir="ltr"><div>Hi folks,</div><div><br></div><div>I am pushing a PoC patch <a href="https://reviews.llvm.org/D70833">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">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>