On Tue, 25 Aug 2026 04:19:07 GMT, Shawn Emery <[email protected]> wrote:
> Perhaps we can address this in another bug? I'm starting to get a little > nervous of the unrelated changes to the double-Keccak GPR feature. I think changing the mentions of `r30` to `lr` ought to be fairly uncontentious. I agree with Andrew's point about the aliasing of `a4` and `a9` being confusing. This is true but it's not so much because of the aliasing but because of the lack of any clear explanation of where, when and why aliasing is being done. Perhaps a restructuring of the code might help but I cannot see any obvious way of avoiding aliasing that results in simpler, clearer code. However, an explanation would go a long way to making things easier for maintainers to follow. So, rather than requiring a rewrite of the algorithm I would recommend adding a header comment as follows: /* * The keccak algorithm needs to read and update 25 input/output data * registers `a[25]` and read 1 input data load address register `rc`. * It also computes up to 5 intermediate values that are all live at the * same time across some part of the computation, `tmp0` ... `tmp4`. * This means that up to 31 independent values are live at once, * preferably stored in registers to avoid having to push and pop * intermediate results. Since `sp` cannot be overwritten this means * that for the best performance every other gpr register needs to be * used to store this data. * * Assuming the caller saves all volatile registers before the call, * then this is possible but only when the OS and JVM configuration * allow reuse of registers `r18` and `rfp`. In this case `r18` and * `rfp` are used by aliasing them to temporaries `tmp3` and `tmp4`. * All other register mappings are determined by the caller. * * If use of `r18` and `rfp` is disallowed then 2 of the 31 live * register values must be pushed to the stack when they are computed * and popped when needed, reducing the count of values that need to * be held live in registers to 29. This frees the registers associated * with the pushed data for reuse as temporaries. Luckily, the algorithm * computes two specific `a[]` values, `a[4]` and `a[9]` well before all * 5 temporary values are live and only needs to reuse those specific * `a[]` values after two of these temporary values, `tmp3` and `tmp4` * are no longer live. In this case, the values computed in `a[4]` * and `a[9]` can be pushed once early during the computation to free * two registers for use as temporaries and popped once later in the * computation when those two temporaries are no longer needed. In * this case `a[4]` and `a[9]` are aliased to temporaries `tmp3` * and `tmp4` for the segment of the computation that lies between * the push and the pop. */ ------------- PR Comment: https://git.openjdk.org/jdk/pull/32049#issuecomment-5408011539
