[JBS] {New} (JDK-8170430) x86 pow() stub from Intel libm is inconsistent with pow() from fdlib

[Vladimir Kozlov]

First, 8170430 is already fixed to resolve issue with libm code.

http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/5a6125eb47aa

Yes, we still have discrepancy between Interpreter and JIT compilers when InlineIntrinsics is off. But we had it for long time.

I agree with Martin that we should have a shared code (for Interpreter and JIT compilers) which choose what to call depending on flags. I filed Bug for jdk 10:

https://bugs.openjdk.java.net/browse/JDK-8170693

Regards,
Vladimir

On 12/2/16 2:17 PM, Deshpande, Vivek R wrote:
> Hi Martin
>
> With the current solution with -InlineIntrinsics it does not go to either SharedRuntime function or Libm based function when its interpreted and goes to SharedRuntime function with C1 and C2.
> So removing this line
>    if (!InlineIntrinsics) return NULL; // Generate a vanilla entry
> from generate_math_entry() seems a correct way, so that with with -InlineIntrinsics option it will always go to SharedRuntime function.
>
> Vladimir, could you please let me know if this sounds ok to you.
>
> Regards,
> Vivek
> -----Original Message-----
> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin
> Sent: Thursday, December 01, 2016 10:07 AM
> To: Andrew Haley; hotspot-compiler-dev at openjdk.java.net
> Subject: RE: [JBS] {New} (JDK-8170430) x86 pow() stub from Intel libm is inconsistent with pow() from fdlib
>
> Hi Andrew,
>
> sounds like a good idea.
>
> At least, the following functions should by in sync:
> Interpreter: TemplateInterpreterGenerator::generate_math_entry
> C1: LIRGenerator::do_MathIntrinsic
> C2: LibraryCallKit::inline_math_native
>
> I think it would be nice to have tables in shared code which translate the respective MethodKind or vmIntrinsics to the function pointers of the SharedRuntime functions.
> I don't like all function calls to get replicated for all platforms.
>
> E.g. generate_math_entry could handle platform specific intrinsics first. If none is available, it could just call the SharedRuntime function retrieved from the shared table.
>
> I believe generate_math_entry should never return 0 because that would mean ending up in StrictMath while C1 and C2 use the SharedRuntime functions. Right?
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley
> Sent: Donnerstag, 1. Dezember 2016 10:15
> To: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: [JBS] {New} (JDK-8170430) x86 pow() stub from Intel libm is inconsistent with pow() from fdlib
>
> I think we should fix up the interpreter and all JITs to call the common routines.  It's not hard, and it will fix non-monotonic behaviour.
>
> Andrew.
>