[LLVMdev] is there some canonical way to extend liveness?

[Andy Ayers]

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>