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

Vladimir Kempik vladimir.kempik at oracle.com
Thu Feb 18 11:41:03 UTC 2016


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

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

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.

More information about the hotspot-compiler-dev mailing list