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.
