RFR: JDK-8300783: Consolidate byteswap implementations [v13]

[Justin King]

On Wed, 15 Feb 2023 12:10:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> src/hotspot/share/utilities/moveBits.hpp line 81:
> 
>> 79:     x = ((x & rep_3333) << 2) | ((x >> 2) & rep_3333);
>> 80:     x = ((x & rep_0F0F) << 4) | ((x >> 4) & rep_0F0F);
>> 81:     return byteswap<T>(static_cast<T>(x));
> 
> If we happen to use this on a platform that has hardware support for bitswap, and the implementation
> of byteswap is an intrinsic, it seems like there might be a risk of interfering with the pattern recognition
> that could transform into the hardware-supported method.

Looks like neither GCC nor Clang are good at recognizing bit reverse, even with the existing implementation. At least based on compiler explorer output. The only way to get Clang to generate `RBIT` on AArch64 is to use `__builtin_bitreverse` or `__rbit` from `<arm_acle.h>`. GCC will also only generate `RBIT` when using `__rbit` from `<arm_acle.h>`. Using `__rbit` won't work to well because we would have to use preprocessor detection to detect whether the target actually has the instruction first. There does not seem like a consistent way to do this across GCC/Clang.

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

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