llvm dev - Jan 2020 - DW_OP_implicit_pointer design/implementation in general

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 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 needs to be represented
> differently inside of LLVM IR?
> >>
> >> I think it's almost entirely that the first argument to
dbg.value will
> >> change from  "Always ValueAsMetadata" to "Maybe
metadata, maybe
> >> Value".
> >
> > What changes do you have in mind there? Are you referring to the
> possibility of implicit values to refer to other variables?
> >
> > I'm sort of interested in maybe not doing that - and only
implementing a
> more general form (what's been talked about with the
LLVM_implicit_value
> (or was it LLVM_explicit_value? I forget)) - and synthesizing artificial
> variables in the backend rather than trying to track which variable a
> pointer points to. I think this would keep the impact on optimizations
> smaller & would be more general. My wager/belief/instinct is that most
> cases won't be pointing to a named variable with a single level of
> indirection, but to unnamed variables, multiple levels of indirection, etc.
>
> The extra artificial variable also strikes me as a DWARF-ism that we
don't
> necessarily should model in LLVM IR.
>
Oh, yeah, that's certainly my intent in making this suggestion, that these
artificial variables would not be part of the LLVM IR and only generated in
the backend (& perhaps not generated at all in some conditions if/where we
decide to support an extension DW_OP that's more similar to what I'm
suggesting to use at the IR level). Thanks for describing/clarifying that
explicitly.

>
> >> I get the feeling that allowing more options here will come
> >> out as more conditions / branching elsewhere, in a way we could
try to
> >> avoid.
>
> If it were possible to synthesize it in AsmPrinter, would that remove the
> motivation for the new intrinsic for you?
>
> -- adrian
>
>
> >>
> >> However it's a mild opinion with a certain amount of hand
waving; and
> >> not one that anyone else seems to share, so I'm happy to drop
that
> >> part of the discussion.
> >>
> >> --
> >> Thanks,
> >> Jeremy
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200113/70781caf/attachment.html>

Hi,

David wrote:
> Are you referring to the possibility of implicit values to refer to other
variables? I'm sort of interested in maybe not doing that - and only
implementing a more general form (what's been talked about with the
LLVM_implicit_value (or was it LLVM_explicit_value? I forget)) - and
synthesizing artificial variables in the backend rather than trying to track
which variable a pointer points to. I think this would keep the impact on
optimizations smaller & would be more general.
Adrian wrote:
> If it were possible to synthesize it in AsmPrinter, would that remove the
motivation for the new intrinsic for you?
Ah, yeah, those changes would avoid any need for a new intrinsic to my
mind, and sounds much more palatable. Thanks for explaining.

--
Thanks,
Jeremy

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.dbg.value -> DBG_VALUE -> DWARF location-list
llvm.dbg.derefval -> DBG_VALUE -> DWARF location-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 intrinsic.

* On the point of handing of pointer pointing to temporary / unnamed
variables (Lets call it Scope S1)
As two proposed patches are there for bringing pointers referring to
temporary / unnamed variable
   A) first patch uses (new proposed operator)
DW_OP_LLVM_explicit_pointer(both in LLVM-IR and DWARF)
   B) Second patch uses artificial variable representing temporary (both in
LLVM-IR and DWARF)
         https://reviews.llvm.org/D72055 [DebugInfo] Support for
DW_OP_implicit_pointer (for temp references & dynamic allocations)
If I understood David correctly, he wants LLVM-IR look like patch-A and
DWARF look like patch-B (lets call it way C)
Since patch-A is not desired because we don't support anything beyond
DWARF-5 and patch proposes new DWARF operator. I want to clarify that
patch-B can exist even without new intrinsic and can use dbg.value and fits
perfectly in existing LLVM-IR template. if only reason to go way-C is to
I would like to go way-B or way-C for the scope of unnamed variables.

* For the cases when pointer points to named variable (Lets call it Scope
S2):
I would update the patches with replacing dbg.derefval to dbg.value and
using DW_OP_implicit_pointer (to named variable) in both LLVM-IR and DWARF.

In summary,
Scope S1 can be solved with
way-B)  DW_OP_implicit_pointer with artificial variable and with intrinsic
dbg.value in LLVM-IR and DWARF
or
way-C) DW_OP_LLVM_explicit_pointer with intrinsic dbg.value in LLVM-IR +
DW_OP_implicit_pointer with artificial variable in DWARF

Scope S2 can be solved with
DW_OP_implicit_pointer with actual named variable with dbg.value in LLVM-IR
and DWARF

Regards,
Alok


Though



lets

On Tue, Jan 14, 2020 at 1:28 AM Jeremy Morse <jeremy.morse.llvm at
gmail.com>
wrote:
> Hi,
>
> David wrote:
> > Are you referring to the possibility of implicit values to refer to
> other variables? I'm sort of interested in maybe not doing that - and
only
> implementing a more general form (what's been talked about with the
> LLVM_implicit_value (or was it LLVM_explicit_value? I forget)) - and
> synthesizing artificial variables in the backend rather than trying to
> track which variable a pointer points to. I think this would keep the
> impact on optimizations smaller & would be more general.
>
> Adrian wrote:
> > If it were possible to synthesize it in AsmPrinter, would that remove
> the motivation for the new intrinsic for you?
>
> Ah, yeah, those changes would avoid any need for a new intrinsic to my
> mind, and sounds much more palatable. Thanks for explaining.
>
> --
> Thanks,
> Jeremy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200114/49b0939f/attachment.html>