search for: statepoint

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 statepo...

...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 appe...

...shes 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> --- lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp | 4 ++-- lib/CodeGen/SelectionDAG/SelectionDAGBuilder.h | 2 +- lib/CodeGen/SelectionDAG/StatepointLowering.cpp | 11 +++++++---- lib/IR/Verifier.cpp | 13 ++++++++----- test/CodeGen/X86/statepoint-call-lowering.ll | 17 +++++++++++++++++ 5 files changed, 35 insertions(+), 12 deletions(-) diff --git a/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp b/lib/CodeGe...

Hi David, Sorry to bother 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...

[+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...

...ce. > > On Tue, Dec 1, 2015 at 8:07 PM, Chen Li <meloli87 at gmail.com <mailto:meloli87 at gmail.com>> wrote: > Hi David, > > Sorry to bother 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...

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...

...landing pad (are there any?), and so probably just reflects my bias coming from dealing with a personality using catchpads/cleanuppads instead of landingpads. 2) Since you're not actually using the landingpad's exception selector nor, if I understand " This is enough to support the gc.statepoint work " correctly, its exception pointer, it's possible that TLI.getExceptionPointerRegister and TLI.getExceptionSelectorRegister should be returning NoRegister for your personality. That would require modifying the EHPersonality enum and corresponding string matching in Analysis/EHPersona...

...r for a garbage collected language, and have a question regarding the current and future support for precise GC in LLVM. It appears that gc.root is being 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 in...

...landing pad (are there any?), and so probably just reflects my bias coming from dealing with a personality using catchpads/cleanuppads instead of landingpads. 2) Since you're not actually using the landingpad's exception selector nor, if I understand " This is enough to support the gc.statepoint work " correctly, its exception pointer, it's possible that TLI.getExceptionPointerRegister and TLI.getExceptionSelectorRegister should be returning NoRegister for your personality. That would require modifying the EHPersonality enum and corresponding string matching in Analysis/EHPersona...

...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 l...

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....

> Vlad, > > My initial impression is that you've stumbled across a bug. I suspect > that we - the only active users of the deopt info in the statepoint I > know of - have been inverting the meaning of Direct and Indirect > throughout our code. (i.e. we're consistent, but swapped on the > documented meaning) I've asked Sanjoy to confirm that, and if he > believes that is actually the case, we will fix upstream to use > Indi...

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 Google's campus o...

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...

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 Mai...

...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 Rea...

Hi, Sanjoy, On 2015-11-16 23:27, Sanjoy Das wrote: > Hi Vlad, > > vlad via llvm-dev wrote: >>> Vlad, >>> >>> My initial impression is that you've stumbled across a bug. I suspect >>> that we - the only active users of the deopt info in the statepoint I >>> know of - have been inverting the meaning of Direct and Indirect >>> throughout our code. (i.e. we're consistent, but swapped on the >>> documented meaning) I've asked Sanjoy to confirm that, and if he >>> believes that is actually the case, we will...