Patch: gcj optimizations

[Andrew Haley]

Bryce McKinlay writes:
 > Tom Tromey wrote:
 > 
 > >Are we guaranteed that the system cos meets Java's requirements?
 > >Andrew dealt with all the Math code in the very early days.  I no
 > >longer remember why we have our own cos instead of relying on the
 > >system one.  Perhaps the system we were using at that time simply
 > >didn't have it.
 > >
 > Maybe  our own cos was needed to meet the stricter Math requirements 
 > before the specification got relaxed?

Yes: the java.lang.Math.cos in our library meets the original Javal
requirements precisely.

 > I don't think it is guaranteed that the system cos meets our 
 > requirements, since the glibc docs warn about systems which do not 
 > support NaN, etc. However, after conducting a small test it looks like 
 > inlined cos works just fine for x86.

Java says:

"for the Math class, a larger error bound of 1 or 2 ulps is allowed
for certain methods."

Intel says:

"On the Pentium processor, the wost case error on functions is less
than 1ulp when rounding to the nearest-even"

Very well.

 > So, perhaps we need a flag to control whether the FP Math.* functions 
 > can be inlined (or replaced with system math lib calls which is what 
 > will actually happen in some cases), which we can then turn on/off in 
 > the libjava configure?

I don't get this.  We need class StrictMath to do what class Math did
originally, and calls to class Math to call builtins where
appropriate, no?

Andrew.