[8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic

[Vladimir Kempik]

Hello

making this routine to always use montgomery_multiply helped to 
workaround the issue

-  if (len >= MONTGOMERY_SQUARING_THRESHOLD) {
+  if (0) {
     ::montgomery_square(a, n, m, (unsigned long)inv, longwords);
   } else {
     ::montgomery_multiply(a, a, n, m, (unsigned long)inv, longwords);
   }

Vladimir.
On 17.02.2016 21:33, Andrew Haley wrote:
> On 02/17/2016 06:19 PM, Vladimir Kempik wrote:
>> I have replaced sub, MACC and MACC2 by c++ version (also changed MACC
>> from defines to inline functions, so changed call to MACC and t0,t1,t2
>> passed by reference) and getting same result, except linux amd64 is
>> failing same way now. So it's probably not asm code that's an issue.
> OK.
>
>> I think my C code works because another test we use to measure speed
>> of BigInteger operations still has 3x improvement in time and it
>> supposed to check the result.
> It's extremely hard to write this stuff in portable C.  I can't tell
> for sure if your code is correct.  It looks reasonable enough.
>
>> http://cr.openjdk.java.net/~vkempik/8130150/asmInC.txt
>>
>> Could it be alloca failing?
> Seems very unlikley.
>
> What would be really helpful would be if you could capture what was
> passed to montgomeryMultiply when the test case fails.
>
> You can perhaps print out all arguments as a string of hex digits
> inside montgomeryMultiply. Then we can debug it.
>
> The real error might be much higher up, though: perhaps some problem
> with the way the builtin is expanded.
>
>> btw, Andrew, in sub asm inline, you modify CF (with clc) but didnt use
>> "cc" at end of asm to notify compiler about it, not sure if that needed tho.
> I already said that in an earlier message.  Needs to clobber "cc".
>
> Andrew.