RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic with AVX2 on x86_64 [v4]

[Volodymyr Paprotski]

On Wed, 19 Mar 2025 19:00:37 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> I was mostly attempting to test 'random paths' through the code, and this was a way to pseudo-randomly accomplish that. (i.e. a product of a difference, a product of a product.. and so on..)
>> 
>> Since this is looping, we got 50% chance of getting both, without me having to write/think-through all the many permutations of what input/outputs to each operations can be.
>> 
>> (Extend the loop count to run for several hours during development.. and it does wonders to testing corner cases. Have been following this 'template' in most my PRs)
>
> Randomness isn't idea for reproducibility.  If a failure occurs, is it obvious what operations were done?  I don't see any stdout or stderr messages to know what operations happen to bring about a possible failure.

I used it this testcase for development (and figured I should also check it in..) so what might be 'obvious' to me, might not be for anyone else?

Typically, when a test failed, I grabbed the SEED from the test output, reran the test with that seed fixed and I went to the exception and printed the hex values of the inputs; (then debug from there. Typically, I would write another test, so I could GDB into the intrinsic, with just those input values). 

It was pretty much always the case always that once I got the inputs, I could reproduce the error i.e. not a type of bug that happens silently then discovered somewhere else. Luckily. All this crypto code is constant-time -no-branches-; so the 'test coverage' here is not 'all-branches-taken' but really 'did you remember to collect all the carries'. like 53-bit limb needs to be propagated back down to 52. Thats what the test here is 'searching' for, some input that could trip up computation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r2004440368