[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal

[Sean Silva]

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

-- Sean Silva


>
> '``llvm.webkit.patchpoint.*``' Intrinsic
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Syntax:
> """""""
>
> ::
>
>       declare void (i32, i32, i8*, i32, ...)*
> @llvm.webkit.patchpoint.void(i32 <id>, i32 <numBytes>, i8* <target>, i32
> <numArgs>, ...)
>       declare i64 (i32, i32, i8*, i32, ...)*
> @llvm.webkit.patchpoint.i64(i32 <id>, i32 <numBytes>, i8* <target>, i32
> <numArgs>, ...)
>
> Overview:
> """""""""
>
> The '``llvm.webkit.patchpoint.*``' intrinsics creates a function call to
> the
> specified <target> and records the location of the live variables in the
> stack
> map.
>
> Arguments:
> """"""""""
>
> The first argument is a unique id, the second is the number of bytes
> reserved for encoding the intrinsic, the third is the target address
> of a function, and the fourth specifies how many of the following
> variable arguments participate in the function call. The remaining
> variable number of arguments are the live variables.
>
> Semantics:
> """"""""""
>
> The patchpoint intrinsic generates the stack map and emits a function call
> to the address specified by <target>. The function call and its arguments
> are lowered according to the calling convention specified at the callsite
> of the intrinsic. The location of the arguments are not normally recorded
> in the stack map. However, special stack-map specific calling conventions
> can force the argument locations to be recorded. The patchpoint also emits
> nops to cover at least <numBytes> of instruction encoding space. Hence, the
> client must ensure that <numBytes> is enough to encode a call to the target
> address on the supported targets. The runtime may patch the code emitted
> for the patchpoint, including the call instruction and nops.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131018/0eac27ca/attachment.html>