On Tue, 12 May 2026 21:20:36 GMT, Volodymyr Paprotski <[email protected]>
wrote:
>> src/java.base/share/classes/sun/security/provider/SHA3Parallel.java line 93:
>>
>>> 91: @IntrinsicCandidate
>>> 92: private static int quadKeccak(long[] lanes0, long[] lanes1, long[]
>>> lanes2, long[] lanes3) {
>>> 93: doubleKeccak(lanes0, lanes1);
>>
>> So, on an architecture that does not provide the `quad_keccak` intrinsic
>> intrinsic but does provide `double_keccak` we will still see two calls to
>> the `doubleKeccak` intrinsic when a call is made to Java method
>> `quadKeccak`. Likewise if we don't have `double_keccak` we can still field
>> this with four calls to a `keccak` intrinsic. Nice!
>
> Yep! Though.. I can't claim the discovery.. "inter-disciplinary" (reads..
> "stolen from" :) ) AES intrinsics.
This would also yield unnecessary processing in the worst-case scenario of
three lanes for AVX2 when using ML-KEM-768, for example. There would be two
full invocations of `doubleKeccak` with the third and fourth calls filled with
only one lane, no?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31125#discussion_r3277873277
