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

[Doerr, Martin]

Hi Vladimir and Vivek,

thank you very much for filing the bug.

I guess x86 is fine, but other platforms return NULL for many entries in generate_math_entry.
That means the interpreter's normal entry will be used which interprets the Math function which calls the StrictMath one.
So finally, the interpreter will compute exact results, while the compilers use the SharedRuntime implementation.

Best regards,
Martin


-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Samstag, 3. Dezember 2016 01:22
To: Deshpande, Vivek R <vivek.r.deshpande at intel.com>; Doerr, Martin <martin.doerr at sap.com>; Andrew Haley <aph at redhat.com>; 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

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.
>