Andy Ayers
2015-Feb-17 20:46 UTC
[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>
Matt Arsenault
2015-Feb-17 21:34 UTC
[LLVMdev] is there some canonical way to extend liveness?
> 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>
Nick Lewycky
2015-Feb-17 21:47 UTC
[LLVMdev] is there some canonical way to extend liveness?
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>
Philip Reames
2015-Feb-18 00:42 UTC
[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 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>
Andy Ayers
2015-Feb-18 02:49 UTC
[LLVMdev] is there some canonical way to extend liveness?
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>