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

[John Rose]

On Jan 5, 2016, at 1:48 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 04/01/16 20:12, John Rose wrote:
>> Corrected, thanks.  They don't need to be intrinsics if they optimize well.
>> The point is that the library functions have code shapes which work well
>> with the JIT.  For example, the multi-index checks might (as in Kishor's code)
>> be implemented on top of the single-index check, without themselves being
>> intrinsics.
> 
> We seem to be missing the opportunity to convert
> 
>  i >= 0 && i < size
> 
> into
> 
>  (unsigned)i < (unsigned)size
> 
> and this is, as far as I can see, the only real code-quality advantage of
> the checkIndex intrinsic.  Could we not do this optimization and then
> drop the C2 checkIndex intrinsic?

…What Paul already said about belts and braces.

Of course we want the JIT to be "sufficiently smart" (tm) to discover the meaning
of all such expressions.

But surely, on balance, it's a good thing to encourage programmers to say what
they mean.

Dropping the intrinsic would prevent them from expressing their intention, forcing them
to fall back on Java's expression operators.  At that point, they have a variety of ways
of indirectly spelling out their intention.  There is no direct contract that the JIT will
understand them, just a hope.  That's not good engineering.

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

— John