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

[Hao Sun]

On Mon, 5 Dec 2022 11:25:04 GMT, Andrew Haley <aph 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.

Thanks a lot for your reviews @theRealAph and @adinn 
Thanks for your invaluable input for the discussion @merykitty

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

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