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>