RFR: 8287925: AArch64: intrinsics for compareUnsigned method in Integer and Long

[Andrew Haley]

On Mon, 28 Nov 2022 02:31:25 GMT, Hao Sun <haosun at openjdk.org> wrote:

> x86 implemented the intrinsics for compareUnsigned() method in Integer and Long. See JDK-8283726. We add the corresponding AArch64 backend support in this patch.
> 
> Note-1: minor style issues are fixed for CmpL3 related rules.
> 
> Note-2: Jtreg case TestCompareUnsigned.java is updated to cover the matching rules for "comparing reg with imm" case.
> 
> Testing: tier1~3 passed on Linux/AArch64 platform with no new failures.
> 
> Following is the performance data for the JMH case:
> 
> 
>                                                        Before          After
> Benchmark                         (size) Mode  Cnt   Score   Error  Score   Error  Units
> Integers.compareUnsignedDirect      500  avgt    5   0.994 ± 0.001  0.872 ± 0.015  us/op
> Integers.compareUnsignedIndirect    500  avgt    5   0.991 ± 0.001  0.833 ± 0.055  us/op
> Longs.compareUnsignedDirect         500  avgt    5   1.052 ± 0.001  0.974 ± 0.057  us/op
> Longs.compareUnsignedIndirect       500  avgt    5   1.053 ± 0.001  0.916 ± 0.038  us/op

The problem as I see it: the intrinsic results in worse performance for the 3-way case if the result is highly predictable.
And, in many cases such as bounds checking, the result will surely be highly predictable.
Therefore, on average, using this intrinsic for the 3-way case may not improve things and could make them worse.

Having said all of that, I believe that directly using the 3-way result may be so rare that we don't need to care about it. All that we really should optimize is the `Integer.compareUnsigned(x,y) cmp 0`.  As long as that doesn't regress, I'm happy.

I won't be working for the next few days, so please don't wait for any more replies from me.

-------------

PR: https://git.openjdk.org/jdk/pull/11383