[llvm-dev] extending liveness of 'this' pointer via FAKE_USE opcode

[Eric Christopher via llvm-dev]

For the record I'm not a huge fan of this idea - mostly because I strongly
believe that debug info should not change code generation. Under a flag
might be ok, but I'd really rather not.

To ask, perhaps, a different question: what kind of debugging experience
are you trying to accomplish here by extending the this pointer? I'm
assuming something about method calls inside other methods? Might we figure
out a different way to accomplish the same task?

Thanks!

-eric

On Tue, Sep 22, 2015 at 12:16 PM Pieb, Wolfgang via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> We thought about putting the ‘this’ pointer into memory but that would
> mean that even small member functions would acquire a stack frame (on
> architectures where leaf routines can get away without one), which may
> degrade performance considerably. You could apply some heuristics and
> determine when a store is unnecessary, but inlining may complicate things.
> A fake_use operation would be inlined like any other instruction.
>
>
>
> We performed some internal evaluations of location coverage (at –O1 on
> x86), and about half of the member functions already had 100% location
> coverage for the this pointer, mostly because they are small. For these
> methods extending the live range to the end of the function would probably
> make no difference in code generation anyway. For the longer routines, a
> fake-use at the end of the function would probably cause a spill early on,
> similar to the effect of an explicit store.
>
>
>
> Another consideration is that we’d like to extend the concept to other
> variables as well.  This ‘this’ pointer Is invariant, but other parameters
> and locals are generally not, so we believe extending the live range would
> be a more general solution.
>
>
>
> -- wolfgang
>
>
>
>
>
> *From:* Smith, Kevin B [mailto:kevin.b.smith at intel.com]
> *Sent:* Monday, September 21, 2015 7:12 PM
>
>
> *To:* Pieb, Wolfgang
> *Cc:* llvm-dev at lists.llvm.org
>
> *Subject:* RE: extending liveness of 'this' pointer via FAKE_USE opcode
>
>
>
> Why extend the live-range?
>
>
>
> If it isn’t already in memory (and for many architectures, it is already
> in memory), put the this pointer into memory, and change the
>
> debug information so that the location-expression of the this parameter is
> marked to be that memory?
>
>
>
> That has two nice properties:
>
>
>
> 1 – If you do this early (in the function IR, not necessarily in the pass
> ordering), it really only costs a single store, and doesn’t otherwise
> really affect register allocation.  Mark the memory itself in such a way
> that it cannot be deleted.
>
>
>
> 2 – This is only required for architectures/calling conventions where the
> this ptr isn’t already in memory, and where this extra debugging is
> required/desired.
>
>
>
> Kevin Smith
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org
> <llvm-dev-bounces at lists.llvm.org>] *On Behalf Of *Pieb, Wolfgang via
> llvm-dev
> *Sent:* Monday, September 21, 2015 11:17 AM
> *To:* llvm-dev at lists.llvm.org
> *Subject:* [llvm-dev] extending liveness of 'this' pointer via FAKE_USE
> opcode
>
>
>
> Hello!
>
>
>
> At Sony we've seen some serious customer interest in having the 'this'
> pointer visible throughout an entire function during
>
> debugging. However, optimizations may eliminate it after its last use, so
> we've been looking for a way to artificially extend its
>
> liverange to the end of the function.
>
>
>
> So far, the most compelling way we can think of, and one we have used
> successfully in the past in at least one other compiler,
>
> is to create a 'fake use' of the 'this' pointer at the end of the
> function, compelling the rest of the compiler to not optimize it away.
>
>
>
> At the moment there doesn't seem to be a good way to create such a fake
> use in LLVM (please enlighten us if you know of one), so we are
>
> proposing to introduce a new intrinsic (e.g. llvm.fake_use), which would
> take a single value argument, representing a use of that value.
>
> The intrinsic would be lowered to a new invariant TargetOpcode (e.g.
> FAKE_USE), which serves the same purpose at the MI level.
>
> Code emission would simply ignore the new opcode.
>
>
>
> Frontends could use the intrinsic to extend liveranges of variables as
> desired. As a first use case, clang would accept a new option
>
> (e.g. -fkeep-this-ptr) which would cause a fake use of 'this' to be
> inserted at the end of a function, making it available for inspection
>
> throughout the entire function body.
>
>
>
> One important note is that since such an option would affect code
> generation, it cannot be automatically enabled by -g. However, should there
> be
>
> eventually support for a -Og mode (optimize for debugging), that mode
> could enable it.
>
>
>
> Any comments or alternative ideas are appreciated.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150922/423a1178/attachment.html>