[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal

[Philip R]

On 10/22/13 10:34 AM, Filip Pizlo wrote:
> 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.
I would argue that while the use of the stack maps might be different, 
the mechanism is fairly similar.  In general, if the expected semantics 
are the same, a shared implementation would be desirable.  This is more 
a suggestion for future refactoring than anything else.

I agree that interior pointers are primarily a problem for relocating 
collectors. (Though I disagree with the characterization of it being 
*uniquely* a problem for such collectors.)  Since I was unaware of what 
you're using your stackmap mechanism for, I wanted to ask.  Sounds like 
this is not an intended use case for you.
>
> 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.
Thanks for the clarification.  This is definitely a useful mechanism.  
Thank you for contributing it back.
>
>> - 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.
Er, possibly I'm misunderstanding you.  To me, a inline call cache is a 
mechanism to optimize a dynamic call by adding a typecheck+directcall 
fastpath.  (i.e. avoiding the dynamic dispatch logic in the common 
case)  I'm assuming this what you mean with the term "call inline 
cache", but I have never heard of a "heap access dispatch inline 
cache".  I've done a google search and didn't find a definition.  Could 
you point me to a reference or provide a brief explanation?

Philip