RFR: 8365732: RISC-V: implement AES CTR intrinsics [v26]
Hamlin Li
mli at openjdk.org
Tue Nov 18 18:27:21 UTC 2025
On Thu, 13 Nov 2025 07:12:38 GMT, Anjian Wen <wenanjian at openjdk.org> wrote:
>> Hi everyone, please help review this patch which Implement the _counterMode_AESCrypt with Zvkned. On my QEMU, with Zvkned extension enabled, the tests in test/hotspot/jtreg/compiler/codegen/aes/ Passed.
>
> Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:
>
> modify stub_id name
Some more comments and questions.
src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2708:
> 2706: // L_encrypt_next:
> 2707: // while (used < BLOCK_SIZE) {
> 2708: // if (len == 0) goto L_exit;
The logic of the code here is different from the logic of assembly code.
Here it checks `len == 0` at the beginning of while loop; assembly code checks `len == 0` at the end of while loop.
Will this difference bring some logic difference in some corner case? If not, why make it a bit different from each other? Does it bring some performance difference with following change?
Label L_next, L_main_loop, L_exit; // remove L_encrypt_next
...
__ bind(L_next);
__ bgeu(used, block_size, L_main_loop);
__ beqz(len, L_exit);
... // scalar processing
__ subi(len, len, 1);
__ j(L_next);
...
__ mv(used, 0);
// Check if we have a full block_size
__ bltu(len, block_size, L_next); // remove L_encrypt_next
...
Ask this question because the change make the comment and assembly implementation consistent, and the code easy to understand.
src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2748:
> 2746: };
> 2747:
> 2748: __ vsetivli(x0, 4, Assembler::e32, Assembler::m1);
A general question, can we make it bigger than `4`, or even `m2`?
-------------
PR Review: https://git.openjdk.org/jdk/pull/25281#pullrequestreview-3479185242
PR Review Comment: https://git.openjdk.org/jdk/pull/25281#discussion_r2539244466
PR Review Comment: https://git.openjdk.org/jdk/pull/25281#discussion_r2539247773
More information about the hotspot-compiler-dev
mailing list