RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions [v20]

[Vladimir Ivanov]

On Wed, 16 Nov 2022 20:52:14 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
>> 
>> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
>> - Added a JMH perf test.
>>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
>> 
>> Perf before:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ± 110554.162  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ±  86696.037  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ±  14074.655  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ±    390.921  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ±      1.402  ops/s
>> 
>> and after:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ± 154528.057  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ±  95253.445  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ± 100847.766  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ±  25883.825  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ±     56.147  ops/s
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   redo register alloc with explicit func params

src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 756:

> 754: 
> 755:   // Store R^8-R for later use
> 756:   __ evmovdquq(Address(rsp, 64*0), B0, Assembler::AVX_512bit);

Could these vector spills be eliminated? I counted 8 spare zmm registers available across the vector loop (xmm7-xmm12, xmm30, xmm31).

And here's what is explicitly used in `process256Loop`:

D0 D1              = xmm2-xmm3
B0 B1 B2 B3 B4 B5  = xmm19-xmm24
TMP                = xmm6
A0 A1 A2 A3 A4 A5  = xmm13-xmm18
R0 R1 R2 R1P R2P   = xmm25-xmm29
T0 T1 T2 T3 T4 T5  = xmm0-xmm5

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

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