JDK 9 RFR of JDK-8139688 Port fdlibm exp to Java

[joe darcy]

Hi Andrew,


On 12/19/2016 7:24 AM, Andrew Haley wrote:
> On 15/12/16 20:25, joe darcy wrote:
>> Hello,
>>
>> Next up in porting fdlibm to Java after cbrt (JDK-8136799), pow
>> (JDK-8134795) and hypot (JDK-7130085) earlier in JDK 9 is exp:
>>
>>       JDK-8139688 Port fdlibm exp to Java
>>       http://cr.openjdk.java.net/~darcy/8139688.5/
>>
>> Same methodology followed as when porting the earlier functions.
> As discussed, this test is pointless because it is always true:
>
> +                if(huge+x>one) return one+x;/* trigger inexact */
>
> I understand that we intend to leave the code untouched, but the
> inexact flag has no effect in Java code.  Does it really make sense
> to translate the code to Java but include such cruft?
>

It may not be clearly evident from the code reviews, but I take an 
iterative approach to porting the fdlibm C code to Java. The first 
iteration is the "transliteration" step where code as close to the C 
code is used and checked into the regression tests as a reference. I 
test the regression tests at this point by running them against JDK 8 
which is still using the C version of fdlibm.

Once that is done, I'll make a number of passes over a copy of the 
transliterated code in the core area to get it closer to idiomatic Java, 
sane whitespace and indenting, use of hex floating-point constants for 
specific values, preferring floating-point vs integer-based value 
checks, etc. One of those passes is removing "extraneous" computations 
which are present to set the IEEE floating-point flags, which as you 
point out, are outside of the Java and JVM model of computation.

With deadlines looming, I didn't get to all the cruft removal passes for 
exp, but that can be done as future work.

Cheers,

-Joe