On 06/15/2015 09:58 AM, Andrew Haley wrote:
On 06/15/2015 05:38 PM, Anthony Scarpino wrote:
On 06/12/2015 04:06 AM, Andrew Haley wrote:
http://cr.openjdk.java.net/~aph/8046943-hs-1/
http://cr.openjdk.java.net/~aph/8046943-jdk-1/
Please don't use the JEP 246 in the comments when you push. There are a
number of changesets related to 246 and I'd rather not have one
associated with it. We can link the a separate bug id to the JEP.
Right.
3. I fused squaring and multiplication into a single
montgomeryMultiply method. This has two advantages. Firstly, we only
need a single intrinsic, and secondly the decision whether to use
multiply or squaring can be made in the runtime library. If the
target does not support the montgomeryMultiply intrinsic there is no
slowdown when using C2 because it removes the if (a == b) test in
if (a == b) {
product = squareToLen(a, len, product);
} else {
product = multiplyToLen(a, len, b, len, product);
}
I don't agree with fusing them together. I think there should two
separate intrinsics. For one, SPARC has a montsqr and montmul
instructions. Additionally if someone wants to call montgomerySquare,
they should be able to call it directly with it's needed number of
arguments and not pass 'a' twice to satisfy an internal if().
OK, fair enough. I'll think a little more about the best way to do
this.
Out of curiosity I just had a look at the SPARC instruction
specifications, and happily (it certainly surprised me!) they are
almost exactly the same as what I've done, so using those instructions
should be a trivial change after this patch. The SPARC instruction
seems to be limited to 32 words (2048 bits) but I guess you'd just use
the software for larger sizes.
Andrew.
Correct, I was prototyping a SPARC intrinsic in May and we independently
had similar methods in BigInteger. At least I believe you had a
montgomerySqr and montgomeryMul method in BigInteger back in April/May.
The instruction gets tedious getting the data to the instruction and the
limitation hurts.
Tony
