similar to: [LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal

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

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

On Oct 18, 2013, at 10:09 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> >> 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

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

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

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

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

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

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

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 04/29/2014 12:39 PM, Filip Pizlo wrote: > On April 29, 2014 at 11:27:06 AM, Philip Reames > (listmail at philipreames.com <mailto:listmail at philipreames.com>) wrote: >> On 04/29/2014 10:44 AM, Filip Pizlo wrote: >>> LD;DR: Your desire to use trapping on x86 only further convinces me >>> that Michael's proposed intrinsics are the best way to go.

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

On Oct 23, 2013, at 5:27 PM, Philip Reames <listmail at philipreames.com> wrote: >> The implementation of the two intrinsics is actually very similar. In this case, the difference would be that llvm.stackmap does not reserve space for patching, while llvm.patchpoint does. > I'm slightly confused by this given that stackmap takes an argument indicating the number of nops to emit

Hi all, It is my understanding that now WebKit depends on the stack map functionality in production. Also, on the mailing lists we've seen lots of users using in this feature. Can we eliminate the experimental status for 3.5? Off the top of my head, the changes needed are: - A read-through of StackMaps.rst to remove any mention of it being experimental. - Removing mention of it being

On 10/23/13 5:38 PM, Andrew Trick wrote: > > On Oct 23, 2013, at 5:27 PM, Philip Reames <listmail at philipreames.com > <mailto:listmail at philipreames.com>> wrote: > >>> The implementation of the two intrinsics is actually very similar. >>> In this case, the difference would be that llvm.stackmap does not >>> reserve space for patching, while