Andrew Trick
2013-Oct-18 05:39 UTC
[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
This is a proposal for adding Stackmaps and Patchpoints to LLVM. The first client of these features is the JavaScript compiler within the open source WebKit project. A Stackmap is a record of variable locations (registers and stack offsets) at a particular instruction address. A Patchpoint is an instruction address at which space is reserved for patching a new instruction sequence at runtime. These two features are close friends because it wouldn't be possible for a runtime to patch LLVM generated code without a stack map telling it where relevant variables live. However, the proposed stackmaps are useful without patchpoints. In fact, the typical use-case for stackmaps is implementing a simple trap to the runtime. Stackmaps are required for runtime traps because without them the optimized code would be dominated by instructions for marshaling values into fixed locations. Even if most of the extra code can be sunk into cold paths, experiments have shown that the impact on compile time and code size is enormous. Explicitly branching to runtime traps handles many situations. But there are also cases in which the runtime needs to patch the runtime call or the surrounding code. There are two kinds of patching we need to support. The first case involves trampling LLVM-generated code to safely invalidate it. This case needs to have zero impact on optimization and codegen aside from keeping some values live. A second case involves dynamically optimizing a short code sequence, for example, to implement a dynamic inline cache. In this case, the commonly executed code must be a call-free fast path. Some runtime events may require rewriting the check guarding the fast path (e.g. to change a type ID) or even rewriting the code the accesses a field to change the offset. Completely invalidating the code at these events is undesirable. Two proposed intrinsics, llvm.stackmap and llvm.patchpoint, solve all of the problems outlined above. The LangRef doc section is included at the end of this proposal. The LLVM implementation of the intrinsics is quite straightforward as you can see from the patches that I'll be sending to llvm-commits. Both intrinsics can generate a stack map. The difference is that a llvm.stackmap is just a stack map. It doesn't generate any code. llvm.patchpoint always generates a call. The runtime may overwrite that call into a dynamically optimized inline cache. llvm.stackmap is simple. It takes an integer ID for easy reference by the runtime and a list of live values. It can optionally be given a number of "shadow" bytes. The shadow bytes may be set to nonzero to ensure that the runtime can safely patch the code following the stackmap. This is useful for invalidating compiled code by trapping at arbitrary points. The LLVM backend emits stackmaps in a special data section. This design works for JITs that are confined to the LLVM C API. Each intrinsic results in a stackmap record with the ID and offset from function entry. Each record contains an entry for each live value with its location encoded as a register or stack offset. llvm.patchpoint is the fusion of a normal call and an llvm.stackmap. It additionally takes a call target and specifies a number of call arguments. The call target is an opaque value to LLVM so the runtime is not required to provide a symbol. The calling convention can be specified via the normal "cconv" marker on the call instruction. Instead of casting a "shadow" where code can be patched it reserves a block of encoding space where the call-to-target will be initially emitted followed by nop padding. Everything about the design and implementation of these intrinsic is as generic as we can conceive at the time. I expect the next client who wants to optimize their managed runtime to be able to do most if not all of what they want with the existing design. In the meantime, the open source WebKit project has already added optional support for llvm.stackmaps and llvm.patchpoint will be in shortly. 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. 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. 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. 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. This allows the runtime to patch the code at this point in response to an event triggered from outside the code. '``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.
Sean Silva
2013-Oct-18 16:37 UTC
[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
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>
Hal Finkel
2013-Oct-18 17:09 UTC
[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
Andrew Trick
2013-Oct-18 18:00 UTC
[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
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>
On 10/17/13 10:39 PM, Andrew Trick wrote:> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The > first client of these features is the JavaScript compiler within the > open source WebKit project. >I have a couple of comments on your proposal. None of these are major enough to prevent submission. - As others have said, I'd prefer an experimental namespace rather than a webkit namespace. (minor) - Unless I am misreading your proposal, your proposed StackMap intrinsic duplicates existing functionality already in llvm. In particular, much of the StackMap construction seems similar to the Safepoint mechanism used by the in-tree GC support. (See CodeGen/GCStrategy.cpp and CodeGen/GCMetadata.cpp). Have you examined these mechanisms to see if you can share implementations? - To my knowledge, there is nothing that prevents an LLVM optimization pass from manufacturing new pointers which point inside an existing data structure. (e.g. an interior pointer to an array when blocking a loop) Does your StackMap mechanism need to be able to inspect/modify these manufactured temporaries? If so, I don't see how you could generate an intrinsic which would include this manufactured pointer in the live variable list. Is there something I'm missing here? - Your patchpoint mechanism appears to be one very specialized use of a patchable location. Would you mind renaming it to something like patchablecall to reflect this specialization? Yours, Philip
Filip Pizlo
2013-Oct-22 17:34 UTC
[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote:> On 10/17/13 10:39 PM, Andrew Trick wrote: >> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The >> first client of these features is the JavaScript compiler within the >> open source WebKit project. >> > I have a couple of comments on your proposal. None of these are major enough to prevent submission. > > - As others have said, I'd prefer an experimental namespace rather than a webkit namespace. (minor) > - Unless I am misreading your proposal, your proposed StackMap intrinsic duplicates existing functionality already in llvm. In particular, much of the StackMap construction seems similar to the Safepoint mechanism used by the in-tree GC support. (See CodeGen/GCStrategy.cpp and CodeGen/GCMetadata.cpp). Have you examined these mechanisms to see if you can share implementations? > - To my knowledge, there is nothing that prevents an LLVM optimization pass from manufacturing new pointers which point inside an existing data structure. (e.g. an interior pointer to an array when blocking a loop) Does your StackMap mechanism need to be able to inspect/modify these manufactured temporaries? If so, I don't see how you could generate an intrinsic which would include this manufactured pointer in the live variable list. Is there something I'm missing here?These stackmaps have nothing to do with GC. Interior pointers are a problem unique to precise copying collectors. In particular, the stackmaps in this proposal are likely to be used for capturing only a select subset of state and that subset may fail to include all possible GC roots. These stackmaps are meant to be used for reconstructing state-in-bytecode (where bytecode = whatever your baseline execution engine is, could be an AST) for performing a deoptimization, if LLVM was used for compiling code that had some type/value/behavior speculations.> - Your patchpoint mechanism appears to be one very specialized use of a patchable location. Would you mind renaming it to something like patchablecall to reflect this specialization?The top use case will be heap access dispatch inline cache, which is not a call. You can also use it to implement call inline caches, but that's not the only thing you can use it for. -Filip> > Yours, > Philip > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Maybe Matching Threads
- [LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
- [LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
- [LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
- [LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
- [LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal