Re: Patch: gcj optimizations

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Eric" == Eric Blake <ebb9@email.byu.edu> writes:

>> We could also inline things like Math.sin, Math.cos, etc.  Doing that
>> would require figuring out how to connect gcj to the builtin function
>> infrastructure in gcc.  This might be tricky; for instance I think
>> we'd want to fall back on calling `java.lang.Math.cos' instead of
>> calling plain `cos' if the builtin is disabled.

Eric> Isn't java.lang.Math.cos specified that it is permitted to be
Eric> native in the first place?

I was thinking about a different issue.

Suppose we change `Math.cos(x)' to `__builtin_cos(x)'.  Then suppose
that the builtin is disabled for some reason (-fno-builtin-cos or
whatever the flag is).  In that case, I believe, gcc will fall back
and emit a call to `cos' -- not `java.lang.Math.cos'.  But with
further investigation I think this doesn't matter, since our Math.cos
just calls cos -- and we also supply cos.  (I'm not 100% sure this is
right.)

As an aside, strict math is something we don't deal with at all yet.
In theory our math is always strict, but I don't know what sort of
testing we've done on that front.  We don't do anything sensible with
`strictfp', and we don't yet implement StrictMath.

Tom