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.