[LLVMdev] Proposal: add intrinsics for safe division

[Philip Reames]

On 05/02/2014 01:00 PM, Andrew Trick wrote:
>
> On May 2, 2014, at 12:54 PM, Eric Christopher <echristo at gmail.com 
> <mailto:echristo at gmail.com>> wrote:
>
>>> I do not like the idea of doing this for safe.div at all, but we could
>>> certainly add more useful semantics to patchpoint without affecting 
>>> WebKit.
>>>
>>
>> I'm curious about this though, what do you have in mind here about sdiv?
>
> division + patchpoints just work the way you would expect
>
> (1) if (division would fail) { call @patchpoint(all of my state) } 
> else { result = a / b }
>
> Good, this is exactly how patchpoints should be used in general. If 
> you're not going to use the div0/overflow result, say because you 
> deoptimize here, you would also have an unreachable on the cold path.
>
> (2) call @safe.div; if (division-failed) { call @patchpoint(my state); 
> unreachable }
>
> Great! In this case, the operation we're checking already gives us the 
> condition we need to check and it's easier to pattern match. Note that 
> this use case alone is not a compelling reason for @safe.div. The good 
> thing about @safe.div is that it can be used for such a wide variety 
> of use cases and in some situations will lead to much better codegen 
> (yes we could get performance data--I don't have it on hand).
>
> -Andy
I've come around to the idea that this can be used to cleanly express 
either explicit deopt-with-branch or trapping loads.  I still don't 
think this is necessarily the best representation, but I can work with it.

By having a pattern match which combines both the structural pattern 
Andy specified above, *and* profiling metadata on the branch, I can get 
either implementation.

I'm still not happy with hiding the explicit control flow, but I can 
achieve the same effect as:
if( div by zero ) throw
(r, o, d) = safe.div(a,b);
if( o ) {
   r = a;
}

i.e. emit a separate guard branch for the interesting condition and not 
utilize the value from the safe div.

Assuming the codegen patterns are right, this should give me options for 
expressing all of the patterns I might like to explore.

Given that, I am okay with the proposed safe.div intrinsics being 
submitted.  It's worth continuing the "patchable call" discussion, but 
that is entirely separate from the original proposal.

Philip



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140502/2937dbba/attachment.html>