Math trig intrinsics and compiler options

gustav trede gustav.trede at gmail.com
Wed Jul 15 13:07:35 PDT 2009


2009/7/15 Tom Rodriguez <Thomas.Rodriguez at sun.com>

>  Thats how i interpret the difference too, and correct me if im wrong  but
>> the rounding is only needed for the strictmath to get its platform
>> independent exact results and not for Math ?.
>>
>
> StrictMath requires exact answers for all of these routines and the intel
> instructions don't have adequate accuracy to be used for them.  The regular
> Math routines have some freedom to differ from the strict implementation but
> they can't be arbitrarily bad and the rounding logic that wraps the
> instructions ensures that we get back valid values outside the range where
> those instructions return reasonable answers.  Check out
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4345903.
>
> As far as why sharedRuntimeTrig.cpp disables compiler optimizations, these
> functions are from fdlibm and require very precise fp semantics which are
> generally violated by the optimizers in most compilers.  If you turn on
> optimizations then these routines won't return the right answer anymore.
>
> tom
>

sharedRuntimeTrig.cpp seems to be ieee754 and should provide the needed
precision for math or
is there any documented empirical evidence or test cases that will break if
the rounding is not in place for the trig methods in Math and hence violates
the 1 ulp and semi monotonic spec for cos and sin ?

If such test case exists, how do i get hold of it ?.
It would make testing of current compiler optimization status easier too.

I assume there is good test cases for this in the JCK, but its not available
for mortal people..


regards
 gustav trede
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090715/8d63ff8f/attachment.html 


More information about the hotspot-dev mailing list