RFR (M): 8143925: Enhancing CounterMode.crypt() for AES

[Vitaly Davidovich]

Does checkIndex match on it? If so, is there a reason to proceed with
intrinsifying checkIndex?

On Wednesday, January 6, 2016, Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> Note, we already have range check pattern matching code in C2 (thanks to
> Roland):
>
> https://bugs.openjdk.java.net/browse/JDK-8137168
>
> Vladimir
>
> On 1/6/16 12:39 PM, Vitaly Davidovich wrote:
>
>> I don't think there's a need to write out 20 different ways to do a
>> range check -- I think nobody would expect all 20 to be covered by the
>> optimizer.  Some of those variations may not map cleanly to
>> Object::checkIndex either, nor is there any guarantee that people will
>> update all their existing range checks (or even know about) to use
>> Object::checkIndex -- some code will be left unoptimized no matter what.
>>
>> But my point is the same as Andrew's, I think; instead of making
>> checkIndex an intrinsic, simply add a pattern match against that exact
>> bytecode shape (perhaps with basic canonicalization) and then still
>> encourage people to use Object::checkIndex.  This is better than
>> intrinsic (modulo profile pollution) since any other code that happens
>> to use same pattern will match as well, and not require an update to use
>> checkIndex.  Then, if someone comes to this list with an unoptimized
>> example with a different bytecode shape and has a convincing argument
>> that the code shape is "common", you guys can consider pattern matching
>> that as well.
>>
>> On Wed, Jan 6, 2016 at 2:50 PM, John Rose <john.r.rose at oracle.com
>> <mailto:john.r.rose at oracle.com>> wrote:
>>
>>
>>      > On Jan 6, 2016, at 9:56 AM, Vitaly Davidovich <vitalyd at gmail.com
>>     <mailto:vitalyd at gmail.com>> wrote:
>>      >
>>      > better canonicalization
>>
>>     That's our first and most important tactic.  (Actually inlining is.)
>>
>>     But the various idioms for checkIndex do not canonicalize easily. In
>>     this case the correct trade-off is not to invest more time and
>>     research and code into stronger canonicalization.
>>
>>     We do have canonicalization of if-expressions. It's just that in
>>     this case strengthening it to cover range checks reliably is harder
>>     than the reasonable alternative.
>>
>>     – John
>>
>>     PS.  I am tempted to write out a list of 20 different ways to code a
>>     range check but will leave that as a exercise.
>>
>>
>>

-- 
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160106/d3e85125/attachment.html>