llvm dev - Oct 2013 - [LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal

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

 -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

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>

On Fri, Oct 18, 2013 at 11:08 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.
>
I'm strongly against naming this "webkit" or anything else to do
with any
other single consumer of LLVM which is not even an LLVM project. It is
really confusing and implies a whole boat of things that aren't true.

I don't understand why you are pushing for "the final name or the
webkit
name". I think the recommendation of "experimental" is great. It
clarifies
that the exact interface isn't fully baked and may change, and clients must
be prepared to update following LLVM trunk as opposed to expecting full
backwards compatibility.

If this feature were *only* applicable to WebKit, I'm not even sure it
would belong in the main open source repository. But it isn't, it's a
really interesting general purpose feature for doing dynamic patching of
call sites, and we should figure out a way to design and evolve it as such.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131018/142115cc/attachment.html>

On Oct 18, 2013, at 11:08 AM, Andrew Trick <atrick at apple.com> wrote:
>> 
>> 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”).
I think that Hal's idea of "experimental" is the right approach
here.  The major thing we want is to avoid having to be backwards compatible
with this intrinsic in subsequent llvm releases.  "experimental" sends
that message, where webkit does not (and is also bad for the reasons Hal
mentions).

-Chris

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