search for: statepoints

I've been looking at inlining invokes / calls done through statepoints and I want to have a design discussion before I sink too much time into something I'll have to throw away. I'm not actively working on adding inlining support to patchpoints, but I suspect these issues are applicable towards teaching LLVM to inline through patchpoints as well. There are...

...the garbage collection right: We would like to be able to implement a moving collector. This requires us to a) find a precise set of root pointers and b) be able to rewrite those pointers after objects moved. LLVM seems to provide two mechanisms for doing this: via "gcroot" and via "statepoints". The [statepoints] documentation indicates the first option, namely "gcroot", is only viable for conservative collectors and statepoints might eventually replace gcroot. So we wanted to try out the statepoints approach. Though it turned out that: * the pass for inserting statepoi...

...nd with a scheme which inserts safepoint polls quite early (but with restricted semantics and optimization impact) and then converts them to explicit GC safepoints (with full invalidation semantics) quite late. We already have this distinction in tree in the form of PlaceSafepoints and RewriteStatepointsForGC. I suspect we'll move further in this direction. I suspect that for languages without deoptimization, you'll want to insert safepoint polls quite late. Whether you do the same for safepoints-at-calls is debatable. I used to think that you should do that quite late, but I'm...

As part of adding `"deopt"` operand bundles, we're aiming to change RewriteStatepointsForGC (called RS4GC henceforth) from rewriting existing `gc.statepoint` calls to transforming normal LLVM calls and invokes into `gc.statepoint` calls and invokes (i.e. to do PlaceSafepoints + RS4GC in one step). This will make `gc.statepoint` an artifact of the gc lowering strategy that only appea...

I actually need this feature quite badly in my untyped language compiler: since I support first-class functions, I've made the types of all functions a standard vararg (so I can box them). The implementation crashes when I try to read out the value of gc.result. Hints as to what might be wrong? Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com> ---

...ou, but I would like to get some suggestions on your recent work of token type. I’m currently working on changing gc.statepoint to return a token type instead of a i32 type. The reason is that with the current implementation, gc.statepoint could potentially be fed into PHI nodes, and break RewriteStatepointsForGC pass later. Using token type would help us to avoid this. I have most of the code work but got a problem when gc.statepint is an InvokeInst and has an unwind path. Currently, gc.statepoint of InvokeInst works as below (the code snippet is from test/CodeGen/X86/statepoint-invoke.ll): %0 = i...

[+CC llvm-dev this time] Hi, As discussed in the review thread in http://reviews.llvm.org/D16439, the future plan around statepoints, deopt bundles, PlaceSafepoints etc. is to "constant fold" -spp-no-statepoints and -rs4gc-use-deopt-bundles to true. We (Azul) have moved to a representation of safepoint polls, deopt state etc. that enables us to do the above; and at this point I'm waiting for an okay from you guys....

...would like to get some suggestions on your recent work of token type. > > I’m currently working on changing gc.statepoint to return a token type instead of a i32 type. The reason is that with the current implementation, gc.statepoint could potentially be fed into PHI nodes, and break RewriteStatepointsForGC pass later. Using token type would help us to avoid this. I have most of the code work but got a problem when gc.statepint is an InvokeInst and has an unwind path. > > Currently, gc.statepoint of InvokeInst works as below (the code snippet is from test/CodeGen/X86/statepoint-invoke.ll):...

Hello, list I am not quite sure if what I'm experiencing is a bug or intentional behavior. In the code below the result of a function call is a deopt arg to llvm.experimental.gc.statepoint (http://llvm.org/docs/Statepoints.html#llvm-experimental-gc-statepoint-intrinsic). Therefore a Stack Map containing location of this variable is created upon code generation. Here's the complete example: define i64 addrspace(1)* @func() { %p = inttoptr i64 42 to i64 addrspace(1)* ret i64 addrspace(1)*...

...you, but I would like to get some suggestions on your recent work of token type. I’m currently working on changing gc.statepoint to return a token type instead of a i32 type. The reason is that with the current implementation, gc.statepoint could potentially be fed into PHI nodes, and break RewriteStatepointsForGC pass later. Using token type would help us to avoid this. I have most of the code work but got a problem when gc.statepint is an InvokeInst and has an unwind path. Currently, gc.statepoint of InvokeInst works as below (the code snippet is from test/CodeGen/X86/statepoint-invoke.ll): %0 = i...

...eing phased out, with with breaking changes such as this: http://reviews.llvm.org/D7004 <http://reviews.llvm.org/D7004> Does this mean that gc.statepoint is ready for primetime (or will be for 3.7's release)? Also, will gc.root still be supported in 3.7 or later? My gut tells me to use statepoints, but after seeing a bunch of TODOs in its implementation in trunk (along with the docs still describing it as experimental), I'm unsure which intrinsics I should be using. thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/piperma...

...you, but I would like to get some suggestions on your recent work of token type. I’m currently working on changing gc.statepoint to return a token type instead of a i32 type. The reason is that with the current implementation, gc.statepoint could potentially be fed into PHI nodes, and break RewriteStatepointsForGC pass later. Using token type would help us to avoid this. I have most of the code work but got a problem when gc.statepint is an InvokeInst and has an unwind path. Currently, gc.statepoint of InvokeInst works as below (the code snippet is from test/CodeGen/X86/statepoint-invoke.ll): %0 = i...

...are all register based, i.e. no alloca, and no readmem, writemem unless accessing/constructing structs. If I use the traditional GC with gcroot intrinsic, it will need to emit more code for liveness tracking, storing the IR values into the gcroot, which seems convoluted. I found using stack map / statepoints very plausible here, because it only needs all live vars without saving it to a corresponding gcroot, and can track liveness at every call point. However, this seems still marked as experimental, and doesn't support exception handling (which is a requirement for my language). And because my la...

Thanks for reviving this. I completely forgot the details but I resolved this problem. Looking though the code, seems I forked RewriteStatepointsForGC pass, and change it to adding 'gc-livevars' bundle to the call/invoke inst after finding the livevars, instead of changing it to StatepointCall intrinsic. On Wed, Nov 14, 2018 at 11:48 AM Philip Reames <listmail at philipreames.com> wrote: > Returning to an ancient thread....

...e of Location except Direct so far). Now I am implementing the safepoint functionality which is why I use the gc.statepoint intrinsic. The two utility passes have been extremely helpful. The use-cases they support are much more general than my needs though. So I use a modified version of RewriteStatepointsForGC, which only appends the pointer values live across the statepoint to <deopt args>. > Philip > > On 11/13/2015 03:17 AM, vlad via llvm-dev wrote: >> Hello, list >> >> I am not quite sure if what I'm experiencing is a bug or intentional >> behavio...

Specifically, I wanted to sit down with Sanjoy and Philip who have been working on getting the current statepoint infrastructure sufficiently well integrated with the optimizer to do early statepoint insertion, and discuss what the path forward is here. If anyone happens to be in the area and is interested in attending, please let me know. Currently, I'm planning to host things up on

Philip Reames wrote: > Any change outside of statepoint lowering is highly suspect. Notice that SelectionDAGBuilder::LowerCallTo (the one I'm modifying) has exactly one other caller: visitCall, which doesn't match vararg functions. Every other codepath directly calls TargetLowering::LowerCallTo, supplying CallLoweringInfo information explicity (it's a structure with a vararg

Hi Chandler, A few of us up here in Seattle would be interested, but we’re too cheap to buy plane tickets. Is it reasonable to set up a conference call? How the optimizer deals with statepoints is important to us. -R From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chandler Carruth Sent: Tuesday, July 28, 2015 8:21 PM To: Sanjoy Das <sanjoy at playingwithpointers.com>; Philip Reames <listmail at philipreames.com>; LLVM Developers Mail...

...Thu, Jul 30, 2015, 08:50 Russell Hadley <rhadley at microsoft.com> wrote: > Hi Chandler, > > > > A few of us up here in Seattle would be interested, but we’re too cheap to > buy plane tickets. Is it reasonable to set up a conference call? How the > optimizer deals with statepoints is important to us. > > > > -R > > > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *Chandler Carruth > *Sent:* Tuesday, July 28, 2015 8:21 PM > *To:* Sanjoy Das <sanjoy at playingwithpointers.com>; Philip Ream...

...am implementing the safepoint functionality which is why I use >> the >> gc.statepoint intrinsic. The two utility passes have been extremely >> helpful. The use-cases they support are much more general than my >> needs >> though. So I use a modified version of RewriteStatepointsForGC, which >> only appends the pointer values live across the statepoint to <deopt >> args>. > > If I understand you correctly, that will work only if your GC isn't a > relocating GC. Is that the case? V8's GC is a relocating GC. When it moves an object which...