[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal

[Andrew Trick]

On Oct 18, 2013, at 9:37 AM, Sean Silva <chisophugis at gmail.com> wrote:

> 
> 
> 
> 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
> they are", then we can just drop the "webkit" name. More likely, we
> will continue improving their functionality for WebKit until some
> point in the future when another JIT customer tells us they would like
> to use the intrinsics but really want to change the interface. At that
> point, we can review this again with the goal of standardization and
> backward compatibility, then promote the name. WebKit is maintained
> against LLVM trunk so can be quickly adjusted to a new interface. The
> same may not be true of other JITs.
> 
> This sort of functionality could probably be used to greatly improve the usability of DTrace's USDT tracing. 
>  
> 
> These are the proposed changes to LangRef, written by Juergen and me.
> 
> WebKit Intrinsics
> -----------------
> 
> This class of intrinsics is used by the WebKit JavaScript compiler to obtain
> additional information about the live state of certain variables and/or to
> enable the runtime system / JIT to patch the code afterwards.
> 
> The use of the following intrinsics always generates a stack map. The purpose
> of a stack map is to record the location of function arguments and live
> variables at the point of the intrinsic function in the instruction steam.
> Furthermore it records a unique callsite id and the offset from the beginning
> of the enclosing function.
> 
> '``llvm.webkit.stackmap``' Intrinsic
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Syntax:
> """""""
> 
> ::
> 
>       declare void (i32, i32, ...)* @llvm.webkit.stackmap(i32 <id>, i32 <numShadowBytes>, ...)
> 
> Overview:
> """""""""
> 
> The '``llvm.webkit.stackmap``' intrinsic records the location of live variables in the stack map without generating any code.
> 
> Last I checked LLVM IR doesn't have "variables" in this sense (except globals; it seems like a handful of other places in the LangRef have this wording slip too). Shouldn't the wording be more like "the run time location of the provided values"?
>  
> 
> Arguments:
> """"""""""
> 
> The first argument is a unique id and the second argument is the number of
> shadow bytes following the intrinsic. The variable number of arguments after
> that are the live variables.
> 
> The purpose of the "id" isn't described.
>  
> 
> Semantics:
> """"""""""
> 
> 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, this is Lang*Ref*, not "LangOverview" or "LangTour"
> 
> It may be that the inherently experimental nature of these intrinsics do not lend itself to being documented adequately enough for inclusion in LangRef at this point, in which case I would suggest demoting this description to a new page for experimental intrinsics until they have settled enough.
> 
> 
> This allows the runtime to patch the code at this point in response to an event triggered from outside the code.
> 
> Here and elsewhere, I suggest avoiding saying "the runtime". It is more accurate to describe properties of the code, rather than the runtime (which LLVM doesn't provide and which is not a concept in the LangRef). For example this sentence could be "This permits the code to be safely patched”.

100% agree with all your comments. I’m pulling the intrinsic docs into a separate page. I’ll create a phabricator diff and we can continue reviewing the docs on llvm-commits independent of this proposal.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131018/1a9a4281/attachment.html>