On Tue, 18 Aug 2026 09:16:31 GMT, Andrew Haley <[email protected]> wrote:

>> This enhancement provides AArch64 GPR intrinsics for doubleKeccak().  
>> Previously, only SIMD (Neon) intrinsics were implemented for doubleKeccak() 
>> on AArch64 systems.  Performance gains for ML-KEM and ML-DSA benchmarks 
>> improve from 2 to 9% with the GPR intrinsics:
>> 
>> ML-KEM decapsulation: +2-6% ops/sec
>> ML-KEM encapsulation: +3-8% ops/sec
>> ML-KEM key generation: +4-6% ops/sec
>> 
>> ML-DSA signing: +2-4% ops/sec
>> ML-DSA verification: +6-9% ops/sec
>> ML-DSA key generation: +6-8% ops/sec
>> 
>> ---------
>> - [X] I confirm that I make this contribution in accordance with the 
>> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai).
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5150:
> 
>> 5148:     __ ldp(a22, a23, Address(state0, 176));
>> 5149:     __ ldr(a24, Address(state0, 192));
>> 5150: 
> 
> This seems to be cut-and-pasted from elsewhere. Please refactor it into a 
> subroutine, and use that everywhere.

Ok, yes, this has probably grown enough to merit a refactor. But do we want 
another subroutine with > 25 arguments? (we already have that with 
`keccak_round_gpr`).

Perhaps a cleaner way to do this would be to manage the register set a0-a24 
here and in the other client of `keccak_round_gpr` using an array:

Register[25] a = {
    r25, r26, r27, r3, r4,
    . . .
    r20, r21, r22, r23, r24,
};


That allows us to use `a[0]`, `a[1]` etc to access what is now written as `a0`, 
`a1` etc. It also means the subroutines only take one `Register[25]` argument 
in place of 25 `Register` arguments and can rely on indexing and looping.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/32049#discussion_r3803038836

Reply via email to