The Graal specific assembly intrinsics for some java.lang.Math transcendental functions have the following issues:
* some of them compute the wrong result (https://github.com/oracle/graal/issues/296)
* for some input values, the result is correct but differs from the result computed by the interpreter, C1 and C2
The immediate solution for this is to make GraalArithmeticStubs[1] false by default and directly use the HotSpot assembly. To do so, requires exposing the HotSpot assembly as a stub instead of simply using the SharedRuntime routines.
The longer term solution (in a separate issue) is to port the HotSpot assembly into Graal. This will avoid the overhead of a stub call and will also benefit SubstrateVM.
* some of them compute the wrong result (https://github.com/oracle/graal/issues/296)
* for some input values, the result is correct but differs from the result computed by the interpreter, C1 and C2
The immediate solution for this is to make GraalArithmeticStubs[1] false by default and directly use the HotSpot assembly. To do so, requires exposing the HotSpot assembly as a stub instead of simply using the SharedRuntime routines.
The longer term solution (in a separate issue) is to port the HotSpot assembly into Graal. This will avoid the overhead of a stub call and will also benefit SubstrateVM.
- duplicates
-
JDK-8156178 [JVMCI] expose StubRoutines trig functions
-
- Resolved
-