On Wed, 9 Nov 2022 16:38:38 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:
> > The way I see it is this: as limbs are 64-bit wide, the only place where > > they can possibly overflow (during the computations they are used for) is > > the multiplication (including multiply by int and squaring). So I would > > first try to change the mult() and square() methods only in > > IntegerPolynomialP256.java (well, in the generator that creates it). > > I agreed. The addition and subtraction operations are limited as well. Each > limb cannot exceed 32 bits, otherwise the carry/reduce may not work as far as > I can see. It would be good the addition and subtraction was placed in > IntegerPolynomialP256.java as well. Otherwise, we have to check the the > limits in the caller level, which is error-prone. > > I will think about how to make this suggestion right. It may be another PR > for the restructure. > I had a further look at the current code structure. The addition counter status is maintained in the caller level (IntegerPolynomial.java). It is possible to re-org the code (the generator), but we may not like the scale of the update. It may not be the purpose of this update. I would like to defer to a separated PR later and keep this PR focus on performance improvement. ------------- PR: https://git.openjdk.org/jdk/pull/10624
