search for: patchpoint

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

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

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

...om>) 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 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 s...

...n to >>> trapping in general. Let's consider the case of Java. A Java >>> program may want to catch the arithmetic exception due to divide by >>> zero. How would you do this with a trap in LLVM IR? Spill all >>> state that is live at the catch? Use a patchpoint for the entire >>> division instruction? >>> >> We'd likely use something similar to a patchpoint. You'd need the >> "abstract vm state" (which is not the compiled frame necessarily) >> available at the div instruction. You could then re-ent...

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

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

...Sanjoy summarized the issues perfectly. > I think the distinction is really between whether the live values are > "live on call" or "live on return". Ideally we should be able to mark > values to be of either kind (liveoncall vs. liveonreturn) in the call > to the patchpoint intrinsic. This will make the semantics of > patchpoint slightly odd though -- we'll end up with an SSA instruction > where some inputs are expected to be live *after* the instruction has > been retired. Are there other SSA instructions that have this sort of > semantics? No, it’...

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

...ced 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 were discussing whether this is the appropriate behavior or not. [Another point about terminology -- the stackmaps documentation refers to the non-function-call arguments as "live values", but we were calling them "deopt values" in person, and I don't particularly li...

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

...fepoint. - It has a variable number of arguments (virtual registers). All can be both read and written. - It can handle any combination of stack locations and registers. Ideally, it should not effect register allocation. The approach I've taken to date is based in part on the work done for PATCHPOINT. Here's what I've done: - Introduced a SAFEPOINT psuedo instruction - Reverse engineered the CALLSEQ_* series of nodes to insert my node after the CALL node in both glue and chain sequences. (BTW, is there any documentation on the call sequence? I think I've reverse engineered it...

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 use a patchpoint to generate a safepoint where I know the locations of my roots by ysing them...

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

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 the location of arguments. > Agreed. My concern is mostly about naming and documentation of intended usages. Speaking as someone w...

...; > The stackmap intrinsic generates no code in place, but its offset from > function > entry is stored in the stack map. Furthermore, it guarantees a shadow of > instructions following its instruction offset during which neither the end > of > the function nor another stackmap or patchpoint intrinsic may occur. It's meaningless to discuss the semantics when important terms are undefined: * "stack map" (and the format of a stack map, and where it is emitted/how it can be accessed, etc.) * "shadow": while it's fairly clear roughly what is meant by this, thi...

...o 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 >>> 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 the location of arguments. >> Agreed. My concern is mostly about naming and documentat...

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

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