RFR: 8287925: AArch64: intrinsics for compareUnsigned method in Integer and Long
Hao Sun
haosun at openjdk.org
Mon Jan 9 09:53:54 UTC 2023
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.
Could you help take another look at this issue when you have spare time? Thanks @theRealAph
-------------
PR: https://git.openjdk.org/jdk/pull/11383
More information about the hotspot-compiler-dev
mailing list