-
Bug
-
Resolution: Unresolved
-
P4
-
9, 10
-
generic
-
generic
Similar to JDK-8170430 code generated by JIT compilers may produce different results depending on flags setting which controls math intrinsics generation and usage. It includes but does not limit to next XX flags:
InlineIntrinsics
DisableIntrinsic
UseMathExactIntrinsics
UseLibmIntrinsic
And other different platform specific intrinsics.
Depending on flags settings next code could be used:
C code from JVM SharedRuntime,
pre-generated code from StubRoutines,
bytecode execution (in case of java implementation presence),
JNI call to native implementation.
Currently Interpreter and JIT compilers use different code which selects what to call:
Interpreter: TemplateInterpreterGenerator::generate_math_entry
C1: LIRGenerator::do_MathIntrinsic
C2: LibraryCallKit::inline_math_native
We should have one place which select what should be used by Interpreter and JIT compilers.
InlineIntrinsics
DisableIntrinsic
UseMathExactIntrinsics
UseLibmIntrinsic
And other different platform specific intrinsics.
Depending on flags settings next code could be used:
C code from JVM SharedRuntime,
pre-generated code from StubRoutines,
bytecode execution (in case of java implementation presence),
JNI call to native implementation.
Currently Interpreter and JIT compilers use different code which selects what to call:
Interpreter: TemplateInterpreterGenerator::generate_math_entry
C1: LIRGenerator::do_MathIntrinsic
C2: LibraryCallKit::inline_math_native
We should have one place which select what should be used by Interpreter and JIT compilers.
- relates to
-
JDK-8170430 x86 pow() stub from Intel libm is inconsistent with pow() from fdlib
-
- Resolved
-
-
JDK-8183232 Avoid resolving method_kind in AbstractInterpreter::can_be_compiled
-
- Resolved
-