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

[Vladimir Kozlov]

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.
>
>