similar to: [LLVMdev] GC Statepoint Transition Status?

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

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 two distinct problems to

The long term plan is a) evolving, and b) dependent on the specific use case. :) It would definitely be nice if we could support both early and late safepoint insertion. I see no reason that LLVM as a project should pick one or the other since the infrastructure required is largely overlapping. (Obviously, I'm going to be mostly working on the parts that I need, but others are always

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

Hello LLVM community, We have been experimenting with using LLVM IR as a target for a managed (dynamically typed) language via an AOT compiler (including a backend for ARM). One main challenge is getting 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

Hi, I'm trying to build a gc using the statepoint-example strategy. However, after hours of searching, reading documentation and trying to find code examples online, I cannot figure out how to access the Stack Map. The documentation for statepoint-example says: The stack map format generated by this GC strategy can be found in the Stack Map

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

That might work. I'm actually particularly interested in your perspective here, so even if it doesn't, I had already planned to specifically email you to make sure I got your thoughts here. But maybe a conference call would work. By far the easiest is for us to do a Google hangout, which would give video and audio. Would that work on your end? On Thu, Jul 30, 2015, 08:50 Russell Hadley

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

Hi Martin, Philip covered all of it very well, I'll just add one minor comment: > More generally, can I back up and ask an important question? Do you have to > support deoptimization (i.e. osr side exits) in any form? If you do, you'll > probably want to avoid the PlaceSafepoints utility pass. If you need to PlaceSafepoints is inadequate only if you have asynchronous

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

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

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

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

Hi, I'm trying to use the statepoint-example strategy to build a simple garbage collector. After using the PlaceSafepoints and RewriteStatepointsForGC passes, I can successfully generate a stack map in my binary and call into my runtime's gc poll. As far as I can tell, I need the stack pointer at the point of the poll to find the correct frame in the stack map. I'm having trouble

Sorry, what does "PC" mean here? ________________________________ From: Philip Reames <listmail at philipreames.com> Sent: Thursday, November 8, 2018 7:27 AM To: Jordan Rudd; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Passing stack pointer to statepoint-gc Jordon, First of all, StackMaps are keyed by PC, not by SP. Each entry corresponds to given location within the

Jordon, I just submitted a change to the docs to hopefully address your confusion.  Can you take a look and let me know if you have further questions?  Start with the revised Stack Map Format section. Philip p.s. I just submitted this and it'll take a few minutes to refresh.  In the meantime, you could look at the diff for 346405. On 11/2/18 2:52 PM, Jordan Rudd via llvm-dev wrote:

Now that the statepoint changes have landed, I wanted to start a discussion about what's next for GC support in LLVM. I'm going to sketch out a strawman proposal, but I'm not set on any of this. I mostly just want to draw interested parties out of the woodwork. :) Overall Direction: In the short term, my intent is to preserve the functionality of the existing code, but migrate

Hi Team, I'm working on a new pure functional language and I'm trying to add GC support for that. Because all vars are immutable, the IR that my frontend generates 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

Hi, My collector supports only base pointers as stack roots. This wasn't a problem until I tried to run some optimizations before RS4GC, which introduced (interior) derived pointers. The statepoint documentation mentions that these collectors exist, but doesn't mention whether and how this is currently supported. What could I do to make it work? -Manuel