[JAVA] Implement more java.lang.Math builtins.

[Roger Sayle]

Hi Andrew,

On Thu, 29 May 2003, Andrew Haley wrote:
> Roger Sayle writes:
>  > The following patch tweaks the gcj front-end to use GCC's built-ins
>  > for the mathematical functions atan, atan2, exp, log, pow and tan
>  > in java.lang.Math builtins.
>
> I'm a bit nervous about this.  The JLS is quite specific about these
> functions and how they are to be computed, whereas (as far as I am
> aware) gcc's builtins are not quite so well-defined.  The efficiency
> argument is compelling, however.
>
> Perhaps we could enable this with a switch; perhaps it doesn't matter.
> Comments welcome...

I'll have to double check the wording in the JLS, but I believe that
its doesn't require anything beyond the appropriate IEEE standards,
with the exception that IEEE FP exceptions can/are/maybe thrown as
java exceptions.

The default behaviour of GCC's built-in mathematical functions is to
only apply an optimization if its guaranteed to produce identical
floating point results without risk of overflow, rounding or exception.
Such as calculating sqrt(2.0) or pow(2.0,3.0) at compile-time.  So
although many language standards permit up to 1 ulp error (or worse),
GCC's middle-end requires a perfect 0.5 ulp for IEEE double by default.

There are also numerous additional optimizations that are only applied
if -ffast-math or -funsafe-math-optimizations is explicitly specified
by the user.  These include optimizations where the result may end up
being incorrectly rounded, or using target specific inline intrinsics
which like the system libraries aren't required to be perfectly
accurate.

And as yet a third safe guard, the java front-end marks these builtins
as explicitly side-effecting, and does not set the pure or const
attributes used by the C, C++ and FORTRAN front-ends.  Hence, while
sqrt(x)+sqrt(x) will be converted into 2*sqrt(x) [or more accurately
y = sqrt(x), y+y] wih -ffast-math in the other front-ends, gcj will
continue to perform the sqrt twice, even with -ffast-math, just in case.


I believe that there's no additional risk.  Java is already using the
sqrt, cos and sin built-ins, probably because these were the only
mathematical builtins available at the time.  My patch just updates
the front-end to reflect the other java.lang.Math functionality thats
now available.

However, if someone could run the jacks, mauve or other conformance
tests on this patch, just to confirm there are no surprises, I'd
really appreciate it.

Roger
--