llvm dev - Feb 2015 - [LLVMdev] is there some canonical way to extend liveness?

In other compilers I've worked on there were special pseudo instructions (or
similar mechanisms like adding extra source operands to returns) that allowed
you to artificially extend lifetimes of values. For instance we might have a
requirement that a certain local (say the 'this pointer') remain live
throughout the method.

Is there anything like this in LLVM?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/4bc1edbe/attachment.html>

> On Feb 17, 2015, at 12:46 PM, Andy Ayers <andya at microsoft.com>
wrote:
> 
> In other compilers I’ve worked on there were special pseudo instructions
(or similar mechanisms like adding extra source operands to returns) that
allowed you to artificially extend lifetimes of values. For instance we might
have a requirement that a certain local (say the ‘this pointer’) remain live
throughout the method.
>  
> Is there anything like this in LLVM?
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
There isn’t a generic mechanism for this, but SI uses a custom pass and pseudos
to accomplish this. See lib/Target/R600/SIFixSGPRLiveRanges.cpp
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/46981593/attachment.html>

On 17 February 2015 at 12:46, Andy Ayers <andya at microsoft.com> wrote:
>  In other compilers I’ve worked on there were special pseudo instructions
> (or similar mechanisms like adding extra source operands to returns) that
> allowed you to artificially extend lifetimes of values. For instance we
> might have a requirement that a certain local (say the ‘this pointer’)
> remain live throughout the method.
>
>
>
> Is there anything like this in LLVM?
>
Do you need this at the IR level? Or in codegen?

In the IR we use SSA, so variables are live exactly as long as they could
be used. There isn't a way to extend lifetimes in the IR per se, you would
need to mark it used in some fashion. For instance adding an intrinsic
@llvm.gc.range.ends.here(%ssavar) and the value needs to live long enough
for that intrinsic to be called. I suppose if it gets called twice, the
subsequent calls are no-ops.

Matt's answer is good if you want it in codegen. Most of the use-cases I
can think of apply to codegen anyways.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/1f05d1be/attachment.html>

I'm assuming that you're asking this in the context of GC?  Are you 
doing conservative stack scanning?

One way you could address this would be to place a gc.statepoint 
immediately before the return with the value you need held live 
mentioned.  This would also give you a precise stackmap at that location 
(for the variables explicitly listed).

Philip

On 02/17/2015 12:46 PM, Andy Ayers wrote:
>
> In other compilers I’ve worked on there were special pseudo 
> instructions (or similar mechanisms like adding extra source operands 
> to returns) that allowed you to artificially extend lifetimes of 
> values. For instance we might have a requirement that a certain local 
> (say the ‘this pointer’) remain live throughout the method.
>
> Is there anything like this in LLVM?
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/294c4315/attachment.html>

Yes, one of the cases comes from GC - at times the code generator must ensure a
particular reference is live and reported at every safepoint. This is in the
context of a precise GC, though there's also a conservative mode that we
plan to use initially until we get the precise GC reporting correct. Either way
that reference must remain live.

We haven't yet decided when or how we'll insert safepoints, though we
had been thinking of doing it fairly early on to provide some opportunity for
optimizers to reason about them.

If I understand the proposal for gc.statepoint correctly, this would be a
degenerate case with no function to call and no use of the relocated value.

From: Philip Reames [mailto:listmail at philipreames.com]
Sent: Tuesday, February 17, 2015 4:42 PM
To: Andy Ayers; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] is there some canonical way to extend liveness?

I'm assuming that you're asking this in the context of GC?  Are you
doing conservative stack scanning?

One way you could address this would be to place a gc.statepoint immediately
before the return with the value you need held live mentioned.  This would also
give you a precise stackmap at that location (for the variables explicitly
listed).

Philip
On 02/17/2015 12:46 PM, Andy Ayers wrote:
In other compilers I've worked on there were special pseudo instructions (or
similar mechanisms like adding extra source operands to returns) that allowed
you to artificially extend lifetimes of values. For instance we might have a
requirement that a certain local (say the 'this pointer') remain live
throughout the method.

Is there anything like this in LLVM?




_______________________________________________

LLVM Developers mailing list

LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu

http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150218/7de26d73/attachment.html>