similar to: [LLVMdev] Representing a safepoint as an instruction in the x86 backend?

Hi all, I don't know if I understand everything, but it seems really interesting for a runtime developer, stackmap and patchpoint looks perfect for a lot of optimizations :) I just have few question to verify if I understand what are these stackmaps and patchpoints, and I discuss the GC after. * I have a first very simple scenario (useful in vmkit). Let's imagine that we want to lazily

I'm moving this to a different thread. I think the newly proposed intrinsic definitions and their current implementation are valuable regardless of how it gets tied into GC... On Oct 22, 2013, at 6:24 PM, Philip R <listmail at philipreames.com> wrote: > Adding Gael as someone who has previously discussed vmkit topics on the list. Since I'm assuming this is where the GC support

Adding Gael as someone who has previously discussed vmkit topics on the list. Since I'm assuming this is where the GC support came from, I wanted to draw this conversation to the attention of someone more familiar with the LLVM implementation than myself. On 10/22/13 4:18 PM, Andrew Trick wrote: > On Oct 22, 2013, at 3:08 PM, Filip Pizlo <fpizlo at apple.com > <mailto:fpizlo

On Oct 22, 2013, at 1:48 PM, Philip R <listmail at philipreames.com> wrote: > On 10/22/13 10:34 AM, Filip Pizlo wrote: >> On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote: >> >>> On 10/17/13 10:39 PM, Andrew Trick wrote: >>>> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The >>>> first client

On Oct 22, 2013, at 3:08 PM, Filip Pizlo <fpizlo at apple.com> wrote: > On Oct 22, 2013, at 1:48 PM, Philip R <listmail at philipreames.com> wrote: > >> On 10/22/13 10:34 AM, Filip Pizlo wrote: >>> On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote: >>> >>>> On 10/17/13 10:39 PM, Andrew Trick wrote:

On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote: > On 10/17/13 10:39 PM, Andrew Trick wrote: >> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The >> first client of these features is the JavaScript compiler within the >> open source WebKit project. >> > I have a couple of comments on your proposal. None of these

On 10/17/13 10:39 PM, Andrew Trick wrote: > This is a proposal for adding Stackmaps and Patchpoints to LLVM. The > first client of these features is the JavaScript compiler within the > open source WebKit project. > I have a couple of comments on your proposal. None of these are major enough to prevent submission. - As others have said, I'd prefer an experimental namespace

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

On 10/22/13 10:34 AM, Filip Pizlo wrote: > On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote: > >> On 10/17/13 10:39 PM, Andrew Trick wrote: >>> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The >>> first client of these features is the JavaScript compiler within the >>> open source WebKit project.

Hi all, I would like to propose a mechanism that would allow LLVM to fold null pointer checks into "nearby" memory operations, subject to runtime support. This is related to but not exactly the same as a proposal floated by Peter Collingbourne earlier [1]. The obvious use cases are managed languages like Java, C# and Go that require a null check on pointers before they're used in

On Wed, Apr 22, 2015 at 11:44 PM, Andrew Trick <atrick at apple.com> wrote: > > This feature will keep being requested. I agree LLVM should support it, > and am happy to see it being done right. +1 > > I plan to break the design into two parts, roughly following the > > statepoint philosophy: > > > > # invokable @llvm.(load|store)_with_trap intrinsics

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

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

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

This is a proposal for adding Stackmaps and Patchpoints to LLVM. The first client of these features is the JavaScript compiler within the open source WebKit project. A Stackmap is a record of variable locations (registers and stack offsets) at a particular instruction address. A Patchpoint is an instruction address at which space is reserved for patching a new instruction sequence at runtime.

Ok I see. Of course, at runtime, it's enough for dynamic linking or for deoptimization. However, wmkit acts both as a jit and as an aot. For the aot, it means that I can not use patchpoint and that I should have two different compilation strategy. It's not so difficult, but in this case, I can not use patchpoints to generate gc's stackmap for the aot (basically, I think that I could

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

Andy - If you're not already following this closely, please start. We've gotten into fairly fundamental questions of what a patchpoint does. Filip, I think you've hit the nail on the head. What I'm thinking of as being patchpoints are not what you think they are. Part of that is that I've got a local change which adds a very similar construction (called

> On Oct 13, 2014, at 4:07 PM, Philip Reames <listmail at philipreames.com> wrote: > > >> On 10/13/2014 03:23 PM, Kevin Modzelewski wrote: >> With the patchpoint infrastructure, shouldn't it now be relatively straightforward to do an accurate-but-non-relocatable scan of the stack, by attaching all the GC roots as stackmap arguments to patchpoints? This is

On May 2, 2014 at 11:53:25 AM, Eric Christopher (echristo at gmail.com) wrote: On Wed, Apr 30, 2014 at 10:34 PM, Philip Reames  <listmail at philipreames.com> wrote:  > Andy - If you're not already following this closely, please start. We've  > gotten into fairly fundamental questions of what a patchpoint does.  >  > Filip,  >  > I think you've hit the nail on