[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal

[Filip Pizlo]

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