search for: patchpoints

...preames.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 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 "statepoints"  > for the moment), but I was trying to keep that separate. That also includes  > a lot of GC semantics which are not under discussion...

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 "statepoints" for the moment), but I was trying to keep that separate. That also includes a lot of GC semantics which are not under discussion currently....

...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 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 "statepoints" > for the moment), but I was trying to keep that separate. That also includes > a lot of GC semantics which are not under discussion...

...ady 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 >> "statepoints" >> > for the moment), but I was trying to keep that separate. That also >> includes >> &gt...

...wanted > to add a new intrinsic that is like a trapping-division-with-stackmap: > > result = call @trapping.div.with.stackmap(a, b, ... all of my state ...) > > Now, maybe you do want such an intrinsic, in which case you should > propose it! > Given what we already have with patchpoints, I don't think a merged intrinsic is necessary. (See above). I believe we have all the parts to build this solution, and that - in theory - they should compose neatly. p.s. The bits I was referring to was not deopt per se. It was particularly which set of deopt state you used for each de...

Hi All, I am observing something i suspect is a misbehaviour of the register allocator which impacts the performance of patchpoints. This occurs in the context of an abstract machine which in some places uses inline caches. The problematic code looks like this: entry: ; Initialize the abstract machine %db = call create_big_seldom_used_database() ; do a lot of things which increases register pressure and spills %db br lab...

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 solve before LLVM can inline through statepoints: # Managing data flow for the extra metadata args. LLVM needs some logic to "transfer" the extra...

Dear All I have some questions about how to use patchpoint intrinsic: 1- The function that is provided as argument to the intrinsic call, where does it belong? I'm making a pass to change a given IR file and add call to patchpoint. Where should I put this function? In the pass or in the same IR file or in another IR and include it or what? 2- When actually this code is patched into the

...ou are interested in using it inside the >> patchpoint. My thoughts are that in that case you might be better off >> including the value as part of the function arguments instead of the >> stackmap/deopt arguments. > > I don't see why anything needs to be different for patchpoints running > with anyregcc. The call arguments always get lowered based on the > calling convention, the "live on call" values get arbitrary stack > slots / registers and the "live on return" values get assigned to CSRs > or stack slots. If I've read X86RegisterIn...

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 build the layout of an object at runtime, i.e., we don't know the layout of the object when we are emitting the code. And, we want to access to a field of this object...

This is a follow up on a conversation some of us had at the hacker lab -- I noticed that sometimes I will get notified that a deopt value lives in a register that is not callee-save (caller-save I guess, but is there another term for this that is less similar to callee-save?). This surprised me quite a bit since those registers immediately got clobbered by the call inside the patchpoint, so we

...----Original Message----- > From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com] > Sent: Tuesday, June 16, 2015 7:20 PM > To: LLVM Developers Mailing List; Andrew Trick; Swaroop Sridhar; Chandler Carruth; Nick Lewycky > Subject: design question on inlining through statepoints and patchpoints > > 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...

I've got a pseudo instruction with some tricky semantics I need help figuring out how to encode properly. For those interested, this is to support fully relocating garbage collection. I'm going to try to express the requirements clearly so that you don't need to understand the use case in detail. My end goal is to capture a list of registers and/or stack offsets for a list of

...f 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 use a patchpoint to generate a safepoint where I know the locations of my roots by ysing them as arguments of the patchpoint?)? Do you think that using a symbol for my targets is easy to implement? Or maybe that there is a...

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

I'll respond to a few questions below. I'll start a new thread for GC discussion. On Oct 22, 2013, at 6:24 PM, Philip R <listmail at philipreames.com> wrote: >> Now with regard to patching. I think llvm.patchpoint is generally useful for any type of patching I can imagine. It does look like a call site in IR, and it’s nice to be able to leverage calling conventions to inform

On Fri, Oct 18, 2013 at 1:39 AM, Andrew Trick <atrick at apple.com> wrote: > > The initial documentation and patches name these intrinsics in a > "webkit" namespace. This clarifies their current purpose and conveys > that they haven't been standardized for other JITs yet. If someone on > the on the dev list says "yes we want to use these too, just the way

On 10/22/13 10:48 PM, Andrew Trick wrote: > I'll respond to a few questions below. I'll start a new thread for GC > discussion. Good idea. Thanks. > > On Oct 22, 2013, at 6:24 PM, Philip R <listmail at philipreames.com > <mailto:listmail at philipreames.com>> wrote: > >>> Now with regard to patching. I think llvm.patchpoint is generally

patchpoint is intended to be used in VMs that do their own linking, and so you wouldn't expect the function parameter to be resolved by LLVM. Presumably, in VMKit, you could just plant a pointer constant to the function you wish to call initially? -Filip On Dec 17, 2013, at 2:42 PM, Gaël Thomas <gael.thomas00 at gmail.com> wrote: > Hi all, > > I'm trying to play with

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