llvm dev - Jun 2014 - [LLVMdev] Stack maps no longer experimental in 3.5

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 experimental from
http://llvm.org/docs/LangRef.html#stack-map-intrinsics
- Removing the `.experimental` from the name.

Anything else?

(also, we'll have to put some stuff in
http://llvm.org/docs/ReleaseNotes.html)

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140606/5530b02c/attachment.html>

On Jun 6, 2014, at 11:10 AM, Sean Silva <chisophugis at gmail.com> wrote:
> 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?
Correct. It is in production software and has multiple clients.

However, it may be worth doing another round of RFC before we pin down the
intrinsic. There is an extension I would like to make, and I want to make sure
we have covered the use cases of other clients that are just considering using
the intrinsic but haven’t finalized their designs.

I planned to send another proposal next week. Based on that discussion we can
determine whether to extend the existing intrinsics or add new intrinsics for
new features.
> 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 experimental from
http://llvm.org/docs/LangRef.html#stack-map-intrinsics
> - Removing the `.experimental` from the name.
> 
> Anything else?
Sounds good.
> (also, we'll have to put some stuff in
http://llvm.org/docs/ReleaseNotes.html)
Right. I’m not in any particular hurry to make 3.5. Let’s see how the discussion
goes next week.

-Andy
> -- Sean Silva
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140606/d1d19f4b/attachment.html>

On Fri, Jun 6, 2014 at 11:29 AM, Andrew Trick <atrick at apple.com>
wrote:
>
> On Jun 6, 2014, at 11:10 AM, Sean Silva <chisophugis at gmail.com>
wrote:
>
> 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?
>
>
> Correct. It is in production software and has multiple clients.
>
> However, it may be worth doing another round of RFC before we pin down the
> intrinsic. There is an extension I would like to make, and I want to make
> sure we have covered the use cases of other clients that are just
> considering using the intrinsic but haven’t finalized their designs.
>
Agreed.
> I planned to send another proposal next week. Based on that discussion we
> can determine whether to extend the existing intrinsics or add new
> intrinsics for new features.
>
*nod*
> 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 experimental from
> http://llvm.org/docs/LangRef.html#stack-map-intrinsics
> - Removing the `.experimental` from the name.
>
> Anything else?
>
>
> Sounds good.
>
> (also, we'll have to put some stuff in
> http://llvm.org/docs/ReleaseNotes.html)
>
>
> Right. I’m not in any particular hurry to make 3.5. Let’s see how the
> discussion goes next week.
>
Sounds good to me. Thanks.

-eric

On Fri, Jun 6, 2014 at 12:29 PM, Andrew Trick <atrick at apple.com> wrote:
>
> On Jun 6, 2014, at 11:10 AM, Sean Silva <chisophugis at gmail.com>
wrote:
>
> 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?
>
>
> Correct. It is in production software and has multiple clients.
>
> However, it may be worth doing another round of RFC before we pin down the
> intrinsic. There is an extension I would like to make, and I want to make
> sure we have covered the use cases of other clients that are just
> considering using the intrinsic but haven’t finalized their designs.
>
> I planned to send another proposal next week. Based on that discussion we
> can determine whether to extend the existing intrinsics or add new
> intrinsics for new features.
>
Cool. Sounds good.

-- Sean Silva

> 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 experimental from
> http://llvm.org/docs/LangRef.html#stack-map-intrinsics
> - Removing the `.experimental` from the name.
>
> Anything else?
>
>
> Sounds good.
>
> (also, we'll have to put some stuff in
> http://llvm.org/docs/ReleaseNotes.html)
>
>
> Right. I’m not in any particular hurry to make 3.5. Let’s see how the
> discussion goes next week.
>
> -Andy
>
> -- Sean Silva
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140606/d428d562/attachment.html>

The only setback is to ensure that we synchronize the renaming with WebKit. 

The WebKit->LLVM interface currently avoids revision-lock; you can take any
recent revision of either and build a working browser engine. This is mostly
true even when we change the stack map format because of versioning in the
format. I'd rather keep it that way.

Is there a way to do this with intrinsics?  I.e. is there a safe way for WebKit
to query whether "llvm.patchpoint" is an available intrinsic, and then
fallback to "llvm.experimental.patchpoint" if it's not available?

-Fil

> On Jun 6, 2014, at 11:10 AM, Sean Silva <chisophugis at gmail.com>
wrote:
> 
> 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 experimental from
http://llvm.org/docs/LangRef.html#stack-map-intrinsics
> - Removing the `.experimental` from the name.
> 
> Anything else?
> 
> (also, we'll have to put some stuff in
http://llvm.org/docs/ReleaseNotes.html)
> 
> -- Sean Silva
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140606/3b2b5130/attachment.html>

On 7 June 2014 00:14, Filip Pizlo <fpizlo at apple.com>
wrote:
> The only setback is to ensure that we synchronize the renaming with WebKit.
>
> The WebKit->LLVM interface currently avoids revision-lock; you can take
any
> recent revision of either and build a working browser engine. This is
mostly
> true even when we change the stack map format because of versioning in the
> format. I'd rather keep it that way.
>
> Is there a way to do this with intrinsics?  I.e. is there a safe way for
> WebKit to query whether "llvm.patchpoint" is an available
intrinsic, and
> then fallback to "llvm.experimental.patchpoint" if it's not
available?
Keeping both names during a smallish time window should be sufficient, no?

Cheers,
Rafael

On 6 Jun 2014, at 19:10, Sean Silva <chisophugis at gmail.com> wrote:
> 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 experimental from
http://llvm.org/docs/LangRef.html#stack-map-intrinsics
> - Removing the `.experimental` from the name.
> 
> Anything else?
Not a blocker, but I'd really like to see someone who understands this code
write a simple tutorial for it.  The current documentation expects a lot of
prior knowledge.

David

On Sat, Jun 7, 2014 at 8:51 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk>
wrote:
> On 6 Jun 2014, at 19:10, Sean Silva <chisophugis at gmail.com> wrote:
>
> > 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 experimental from
> http://llvm.org/docs/LangRef.html#stack-map-intrinsics
> > - Removing the `.experimental` from the name.
> >
> > Anything else?
>
> Not a blocker, but I'd really like to see someone who understands this
> code write a simple tutorial for it.

A tutorial for this feature would mostly overlap with an MCJIT tutorial. I
believe it would be better to have a good MCJIT tutorial and then a
separate page describing the key places where the plain MCJIT tutorial
would need to be modified to utilize the stack map functionality.

>  The current documentation expects a lot of prior knowledge.
>
Well, making any use of the feature basically requires the user to patch
machine-code, and IMO that's the biggest hurdle (teaching machine-code
patching certainly isn't germane for a document targeted at a specific LLVM
feature).

For someone already familiar at a machine-code level with their
architecture of interest, then the feature is conceptually extremely
simple: it just gives you some guarantees about the structure of the
machine code at particular addresses and also gives you information about
where IR-level values are stored at run-time. More precisely:
- Both llvm.experimental.stackmap and llvm.experimental.patchpoint can
record the run-time location of IR-level values.
- Both can reserve space (a "shadow") in the machine code, but with
different guarantees: llvm.experimental.patchpoint makes sure that the
reserved region doesn't contain any other code besides a call of your
choosing (and nops if needed), while llvm.experimental.stackmap just
ensures (with nops if needed) that if you overwrite that space that you
will not be writing outside the function itself (this is meant for
destructively patching the following machine code).
These bullets are basically just a rehashing of:
http://llvm.org/docs/StackMaps.html#intrinsics

For someone comfortable patching machine code, the only difficulty I can
imagine are just janitorial details (such as setting up MCJIT or processing
the stack map data structure) to get snagged on, which can be covered in a
targeted (not tutorial) way.

-- Sean Silva

>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140607/e97a223e/attachment.html>