RFR: 8316592: RISC-V: implement poly1305 intrinsic [v9]
Hamlin Li
mli at openjdk.org
Mon Nov 13 14:40:09 UTC 2023
On Mon, 13 Nov 2023 09:39:52 GMT, ArsenyBochkarev <duke at openjdk.org> wrote:
>> If the above issue is not a false one, and the implemention was tested with existing jdk test suite, then I'm afraid we need to add more test to catch this issue.
>
> Please correct me if I'm wrong:
>
> 1. In first loop iteration: after `poly1305_pack_26` before the loop `U_2` is `0b11` max. After any loop iteration the max for `U_2` is `0b100` (as we found out earlier);
> 2. After `Add U_0 to S_0`: the carry is `0b1` max, plus mandatory `addi` of `0b1` to `S_2` --> `S_2` is `0b110` max;
> 3. After `wide_mul`'s and `wide_madd`'s: `U_2` is again `0b11` max due to `andi(U_2, R_0, bits2)` (and even `0b0` in case of `0b100` in first step). NB: inside `wide_*` functions `S_2` is unchanged;
> 4. `mul(U_2, S_2, U_2)`: `U_2` is `0b1111` max --> in `poly1305_reduce` the `tmp1` is `0b11` max, which is safe?
Did the above derivation process consider adc(U_2, U_2, U_1HI, t1); at L4564?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16417#discussion_r1391201066
More information about the hotspot-compiler-dev
mailing list