On Tue, 3 Nov 2026 06:55:52 GMT, Jatin Bhateja <[email protected]> wrote:
>> Hi All,
>>
>> x86 AVX-512 targets provides packed shifts for 16, 32, and 64-bit lanes, but
>> not for bytes. C2 lowers LShiftVB, RShiftVB, and URShiftVB by widening bytes
>> to words, shifting, masking, and packing. That sequence is the byte-shift
>> bottleneck.
>>
>> GFNI **gf2p8affineqb** instruction applies one 8×8 bit matrix to every byte.
>> Logical left, logical right, and arithmetic right shifts by 0..7 are fixed
>> matrices derived from the identity 0x0102040810204080.
>>
>> Patch uses this lowering for 128-, 256-, and 512-bit vectors when GFNI is
>> available and keeps the existing widen/shift/pack path when GFNI is absent.
>>
>> Following are the performance numbers of benchmark included with the patch.
>>
>> System: AMD EPYC 9755 128-Core Processor (Turin) Fixed frequency 2.5Ghz
>>
>> Baseline:-
>> ----------
>> Benchmark (shift) Mode Cnt Score Error
>> Units
>> ByteShiftBenchmark.ashr128 3 thrpt 2 24994.026
>> ops/us
>> ByteShiftBenchmark.ashr256 3 thrpt 2 29289.608
>> ops/us
>> ByteShiftBenchmark.ashr512 3 thrpt 2 39944.806
>> ops/us
>> ByteShiftBenchmark.autoVecAshr 3 thrpt 2 32592.174
>> ops/us
>> ByteShiftBenchmark.autoVecLshl 3 thrpt 2 30668.901
>> ops/us
>> ByteShiftBenchmark.lshl128 3 thrpt 2 25247.149
>> ops/us
>> ByteShiftBenchmark.lshl256 3 thrpt 2 27345.375
>> ops/us
>> ByteShiftBenchmark.lshl512 3 thrpt 2 38500.755
>> ops/us
>> ByteShiftBenchmark.lshr128 3 thrpt 2 25081.398
>> ops/us
>> ByteShiftBenchmark.lshr256 3 thrpt 2 28272.477
>> ops/us
>> ByteShiftBenchmark.lshr512 3 thrpt 2 42186.028
>> ops/us
>>
>> Withopt:-
>> ---------
>> Benchmark (shift) Mode Cnt Score Error
>> Units
>> ByteShiftBenchmark.ashr128 3 thrpt 2 31313.173
>> ops/us
>> ByteShiftBenchmark.ashr256 3 thrpt 2 58663.746
>> ops/us
>> ByteShiftBenchmark.ashr512 3 thrpt 2 50472.509
>> ops/us
>> ByteShiftBenchmark.autoVecAshr 3 thrpt 2 44965.109
>> ops/us
>> ByteShiftBenchmark.autoVecLshl 3 thrpt 2 46304.515
>> ops/us
>> ByteShiftBenchmark.lshl128 3 thrpt 2 28849.321
>> ops/us
>> ByteShiftBenchmark.lshl256 3 thrpt 2 40492.534
>> ops/us
>> ByteShiftBenchmark.lshl512 3 t...
>
> Jatin Bhateja has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Review comments resolution
src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1433:
> 1431: // One matrix per count in 0..31.
> 1432: const int mats_per_kind = 32;
> 1433: lea(rbase,
> ExternalAddress(StubRoutines::x86::vector_byte_shift_gfni_matrix() + kind *
> mats_per_kind * BytesPerLong));
How does it work with AOT code caching? Only base address is known to the JVM,
so it can miss updating the address in generated code when loading it from AOT
cache.
src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 1444:
> 1442: static const uint64_t mats[3][8] = {
> 1443: // logical left
> 1444: { 0x0102040810204080ULL, 0x0001020408102040ULL,
> 0x0000010204081020ULL, 0x0000000102040810ULL,
I find it easier to read when it is formatted like a matrix:
{ 0x0102040810204080ULL,
0x0001020408102040ULL,
0x0000010204081020ULL,
0x0000000102040810ULL,
0x0000000001020408ULL,
0x0000000000010204ULL,
0x0000000000000102ULL,
0x0000000000000001ULL },
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/33113#discussion_r4460180976
PR Review Comment: https://git.openjdk.org/jdk/pull/33113#discussion_r4460195881
