similar to: Status of Garbage Collection with Statepoints in LLVM

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

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

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

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

TLDR. For anyone who is using the RewriteStatepointsForGC utility pass, there is a recent change you should know about which may require you to make some small changes to your stackmap parsing. I have landed a small series of patches which change how we're handling vector of pointers when reporting live pointers for the GC at safepoints. Previously, the RS4GC pass was attempting to

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, I am looking to utilize LLVM as the backend in an existing compiler 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

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

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

Thanks for the feedback. I think both of the suggestions are very reasonable. I’ll incorporate them. Given there were no objections for two weeks, I’m going to go ahead with posting individual patches for review. One small question inline: On Sep 28, 2020, at 10:56 AM, Philip Reames <listmail at philipreames.com<mailto:listmail at philipreames.com>> wrote: In general, I am

TLDR: a proposal to add GC-parseable lowering to element atomic memcpy/memmove instrinsics controlled by a new "requires-statepoint” call attribute. Currently llvm.{memcpy|memmove}.element.unordered.atomic calls are considered as GC leaf functions (like most other intrinsics). As a result GC cannot occur while copy operation is in progress. This might have negative effect on GC latencies

As I've mentioned on the mailing list a couple of times over the last few months, we've been working on an approach for supporting precise fully relocating garbage collection in LLVM. I am happy to announce that we now have a version of the code available for public view and discussion. https://github.com/AzulSystems/llvm-late-safepoint-placement

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>

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

Thanks for the comments and for taking a look. On 06/05/2014 02:19 AM, David Chisnall wrote: > Hi Philip, > > The first thing that I notice on looking at the code is the lack of comments. For example, about the only comment that I see in include /llvm/IR/Statepoint.h is a note telling me that a class is only intended to be used on the stack. Doxygen comments and, for a feature like

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

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

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