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

[Andrew Haley]

On 05/01/16 22:11, John Rose wrote:

> Dropping the intrinsic would prevent them from expressing their
> intention, forcing them to fall back on Java's expression operators.

I don't really understand that point: Objects.checkIndex would still
exist, and hopefully people would use it, but it wouldn't need
special-case handling in C2.

> Also, it's not just a matter of micro-optimizing a single expression
> to use unsigned arithmetic (though that is surprisingly tricky).

I accept that point.

> Range checks are interesting to block-level loop transformations
> (iteration range reorganization).  Do you really want your loop
> optimizations to be gated on "sufficient smarts" in the JIT's
> expression pattern matcher?

Please forgive me for pushing this: I'm not arguing for the sake of it,
I'm trying to understand your reasoning.

As it stands we recognize a call to Objects.checkIndex and transform
it into a certain pattern.  I'm assuming that it's not impossible to
recognize the logic inside Objects.checkIndex and transform it into
the same form that the intrinsic generates.  And that would have a
payoff in all the places that the same logic is used in existing
programs, both inside and outside the JDK.

I suppose one downside of this approach is that C2 might decide
not to inline Objects.checkIndex, so it would be called instead
and the optimization would not be done.

Andrew.