RFR(S): 8209544: AES encrypt performance regression in jdk11b11

[Andrew Haley]

On 09/20/2018 03:54 PM, Roland Westrelin wrote:
> 
>> mkay, but how, exactly? Is it simply the case that Intel is improved
>> so the patch is good, even if AArch64 regresses?
> 
> Well, no, I don't think that's an accurate description of what this
> is. Dmitry reported a performance regression but the generated code is
> almost identical with or without the patch (the only difference being
> that in one case the generated code uses b.cc and in the other
> b.eq). Dmitry also hypothesized that branch prediction may not perform
> as well with the patch. That doesn't seem directly related to the patch
> but more of an unfortunate side effect. So the patch simplifies the IR
> so less instructions may need to be emitted. That's not x86 specific. It
> just happens that aarch64 don't seem to be able to take advantage of it
> but it doesn't increase the number of instructions that aarch64 needs
> either or forces aarch64 to use less efficient instructions. So overall,
> it seemed to me there was no reasonable reason to not push this patch.

OK, I see. I agree that reasoning is sound. We already know that
perfectly reasonable improvements to JITs occasionally cause
regressions in some cases, but that's not a reason to reject such
improvements.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671