[LLVMdev] Proposal: add intrinsics for safe division

[Philip Reames]

Ok, let's take a major step back.  I think we're getting too much into 
the details of the current implementation and loosing track of the use 
cases.

 From what I can tell, there are a number of possible uses for 
"patchable calls" or "stack maps".  Note, I'm purposesly not using the 
term "patchpoint" here.  Let's walk through from first principles and 
make sure we're in agreement.  Once we've got that, we can figure out 
how to evolve patchpoint as needed (if needed).

Call Dispatch Optimizations (i.e. inline call cache) -- In this case, 
the final callee is unknown at the call site.  The purpose is to cache 
the result of the function resolution (virtual call, interface call, 
"other" call).  The actual call target may change, so little is known 
about the callee.  In theory, the optimizer could leverage information 
about the set of functions potentially reachable, but that information 
is not exposed today.

Code Lifetime Management - If one compiled function calls another, it 
may be necessary to redirect this call to another implementation of the 
same function.  (In the most common case, this would be an 
interpreter.)  In this case, the callee is always the same and the call 
site can be optimized with that assumption provided the ability to 
redirect the actual call is preserved.

Unpatched Call w/stack map - The runtime may need to know the state of 
certain values during the call.  Conceptually, these values become 
arguments to the function, but the calling convention is highly flexible 
to reduce the call overhead.  In this usage, the call site is not 
patched, but the stack map is required.  The call target is known and 
can be used for optimization purposes.

Opaque Patching - The runtime is going to patch in some completely 
unknown bit of code at this location.  This is completely opaque to the 
optimizer.

Are there any cases I've missed?

Let's move on to the existing implementations.

As far as I can tell, Filip expects the "opaque patching" semantics, but 
is actually implementing something closer to the "call dispatch 
optimization".  I was expecting that the existing implementation could 
be used for any of the above, but got confused about optimizations which 
were legal only for "lifetime management" and "unpatched calls w/stack 
maps" and tried to apply them to patchpoint as a whole.

At least to my reading, the current documentation would seem to indicate 
that all uses above are legal, but only optimizations applicable to all 
would be legal.  (i.e. none)  The last half could stand to be clarified 
in the documentation.

Is this a correct summary of the discussion to date?


It's starting to sound like we need a split within the "patchpoint" 
intrinsic.  We need one version which provides *no* information about 
the eventual callee.  We need another which provides the "patchable" 
part, but also specifies some information about the eventual callee for 
the purpose of optimization.  Potentially, we even need a version which 
has a "stack map", but isn't patchable.

Thoughts?  This isn't a concrete proposal or anything.  If we settle on 
something, I'll make a more formal proposal with a proper spec for 
general discussion.

Philip





On 04/30/2014 10:57 PM, Filip Pizlo wrote:
*Conversation trimmed to avoid moderation due to length*