RFR(M): 7133857: exp() and pow() should use the x87 ISA on x86

[Vladimir Kozlov]

Could you replace notEqual with notZero, yes it the same but notZero is more fit 
here (you have 2 places):

+      testl(tmp2, tmp2);
+      jcc(Assembler::notEqual, integer);

Why you need the next move?:

+      mov(rcx, tmp2);
+      Label integer;

Next sequence (64bit VM):

+      testl(tmp2, tmp2);
+      jcc(Assembler::notEqual, integer);
+      shrq(tmp2, 32);
+      cmpl(tmp2, 0x80000000);
+      jcc(Assembler::notEqual, integer);

could be:

+      shlq(tmp2, 1);
+      jcc(Assembler::carryClear, integer);
+      jcc(Assembler::notZero, integer);

Vladimir

Roland Westrelin wrote:
> 
> While adding comments as suggested by Vladimir, I realized that my fix:
> 
>> Also one corner case was not well handled by the interpreter/c1 
>> assembly code. For x^y, when x < 0, y has to be an integer and we need 
>> to test whether it's odd or even. The previous code would fallback to 
>> the runtime code if y was too large for a 32 bit integer. So for 
>> instance Math.pow(x,y) with x < 0 and a large y would be computed by 
>> the C code but Math.pow(-x, y) which should be +/- Math.pow(x, y) 
>> depending on y's parity would be computed by the assembly code and 
>> results would differ. So on the x < 0 code path, I now check for y+1 
>> == y which is true for very large numbers that are all even and if the 
>> test fails I use a 64 bit rather than a 32 bit integer which is 
>> guaranteed to not overflow for numbers where y+1 != y.
> 
> was correct but could be simpler. So here is one more webrev:
> 
> http://cr.openjdk.java.net/~roland/7133857/webrev.03/
> 
> In the case where x < 0 and y is huge: y is even. y may not fit in a 64 
> bit integer and then we'll get the integer indefinite value which is 
> even as well.
> 
> So either y fits in a 64 bit integer and we can test its parity or y 
> doesn't fit in a 64 bit integer, y is even and we get an even indefinite 
> value so the result of the parity test is correct.
> 
> So I turned the code that checks y+1 == y that I added in the 2nd webrev 
> into debug code and the only change compared to the first webrev for 
> non-debug code is that I use a 64 bit rather than a 32 bit integer in 
> the x < 0 code path.
> 
> Roland.