[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal

Andrew Trick atrick at apple.com
Fri Oct 18 11:08:27 PDT 2013 

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 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.
> 
> I recommend, this being the case, to replace 'webkit' with 'experimental'. Having webkit in the name implies some dependence on webkit, and there is none. Plus, this functionality will be used by outside projects as soon as it lands in trunk, and I suspect that having webkit in the initial name will end up as a naming incongruity that no one will really think is worth the effort to change.

You’re correct that there is no dependence. I’m fine dropping the webkit name, but only if we can go straight to the final name (no need for “experimental”).

Again, the only reason to start with the webkit name is that it’s easy to change webkit later to use different intrinsics. I was waiting to see how much interest there is in using these instrinsics as-is for other clients. So far, there seems to be strong interest. If there isn’t much debate regarding the intrinsic format then I’ll drop the webkit name.

>> 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.)
> 
> I'd like to second this; we need to document the format of the stack map. We might want to do this in a separate document (like the document which elaborates on the description of the exception handling intrinsics). This document should be seeded with, at least, the description for x86 (and we can add descriptions for the other backends as they're validated).
> 
> This looks like a very-useful piece of functionality.

I’m moving the intrinsic docs to a separate page, like exception intrinsics, and documenting the stack map format there.

-Andy

> 
> -Hal
> 
>> * "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
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory

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

More information about the llvm-dev mailing list