[llvm-dev] DW_OP_implicit_pointer design/implementation in general

[Jeremy Morse via llvm-dev]

Hi,

For a new way of representing things,

Adrian wrote:
> llvm.dbg.value_new(DILocalVariable("y"), DIExpression(DW_OP_LLVM_arg0, DW_OP_LLVM_arg1, DW_OP_plus),
>                    %ptr, %ofs)

I think this would be great -- there're definitely some constructs
created by the induction-variables pass and similar where one could
recover an implicit variable value, if you could for example subtract
one pointer from another.

With the current model of storing DIExpressions as a vector of
opcodes, it might become a pain to salvage a Value that gets optimised
out --in the example, if %ofs were salvaged, presumably
DW_OP_LLVM_arg1 could have to be replaced with several extra
operations. This isn't insurmountable, but I've repeatedly shied away
from scanning through DIExpressions to patch them up. A vector of
opcodes is the final output of the compiler, IMHO richer metadata
should be used in the meantime.

IMHO the implicit pointer work doesn't need to block on this. As said
my mild preference would be for a new intrinsic for this form of
variable location.

~

Inre PR37682,

> 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.

This has been working through my mind too, and I think it's slightly
different to what implicit_pointer is trying to achieve. In the case
implicit_pointer is designed for, it's a strict improvement in debug
experience because you're recovering information that couldn't be
expressed. However for PR37682 it's a trade-off between whether the
user might want to examine the pointer, or the pointed-at integer:
AFAIUI, we can only express one of the two, not both. Wheras for
mem2reg'd variables referred to by DIE, there is never a pointer to be
lost.

I think my preference would always be to see temporarily-promoted
values as there's no other way of observing them, but others might
disagree.

--
Thanks,
Jeremy