[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal

[Philip R]

On 10/22/13 3:08 PM, Filip Pizlo wrote:
>
> On Oct 22, 2013, at 1:48 PM, Philip R <listmail at philipreames.com 
> <mailto:listmail at philipreames.com>> wrote:
>
>> On 10/22/13 10:34 AM, Filip Pizlo wrote:
>>> On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com 
>>> <mailto: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.
>
> It's not at all similar.  These stackmaps are only useful for 
> deoptimization, since the only way to make use of the live state 
> information is to patch the stackmap with a jump to a deoptimization 
> off-ramp.  You won't use these for a GC.
>
>> 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 think that these stackmaps and GC stackmaps are fairly different 
> beasts.  While it's possible to unify the two, this isn't the intent 
> here.  In particular, you can use these stackmaps for deoptimization 
> without having to unwind the stack.
I'm going to respond to Andrew Trick's followup for this portion.
>
>>
>> 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.
>
> Inline caches don't have to be calls.  For example, in JavaScript, the 
> expression "o.f" is fully dynamic but usually does not result in a 
> call.  The inline cache - and hence patchpoint - for such an 
> expression will not have a call in the common case.
>
> Similar things arise in other dynamic languages.  You can have inline 
> caches for arithmetic.  Or for array accesses.  Or for any other 
> dynamic operation in your language.
>
>>  (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?
>
> Every JavaScript engine does it, and usually the term "inline cache" 
> in the context of JS engines implies dispatching on the shape of the 
> object in order to find the offset at which a field is located, rather 
> than dispatching on the class of an object to determine what method to 
> call.
Thank you for the clarification.  I am familiar with the patching 
optimizations performed for property access, but had not been aware of 
the modified usage of the term "inline cache".  I was also unaware of 
the term "heap access dispatch inline cache".  I believe I now 
understand your intent.

Taking a step back in the conversation, my original question was about 
the naming of the patchpoint intrinsic.  I am now convinced that you 
could use your patchpoint intrinsic for a number of different inline 
caching schemes (method dispatch, property access, etc..).  Given that, 
my concern about naming is diminished, but not completely eliminated.  I 
don't really have a suggestion for a better name, but given that a 
"stackmap" intrinsic can be patched, the "patchpoint" intrinsic name 
doesn't seem particularly descriptive.  To put it another way, how are 
the stackmap and patchpoint intrinsics different?  Can this difference 
be encoded in a descriptive name for one or the other?

As a secondary point, it would be good to update the proposed 
documentation with a brief description of the intended usage (i.e. 
inline caching).  This might prevent a future developer from being 
confused on the same issues.

Yours,
Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131022/95a66c5f/attachment.html>