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

[Vladimir Kozlov]

On 11/30/16 9:35 AM, Volker Simonis wrote:
> Hi,
>
> what is the actual problem here? Is it the fact that Math.pow()
> returns different results depending on whether it is executed in
> interpreted or in JIT-compiled mode?
>
> Or in other words - do we insist on having the same results from the
> Math functions while promoting from Interpreted to C1 and finally C2?

Yes, that is the goal. The result should be the same from Interpreter and from code generated by JIT compilers.

> The API-doc for Math says: "Unlike some of the numeric methods of
> class StrictMath, all implementations of the equivalent functions of
> class Math are not defined to return the bit-for-bit same results.
> This relaxation permits better-performing implementations where strict
> reproducibility is not required." But I'm not sure if this implies
> that Math.FUNC(constant_value) always has to return the bit-for-bit
> same result no matter how often we call it?
>
> The problem is that by default the Java implementation of the Math
> functions call the StrictMath version. So if the interpreter does no
> optimizations, it will get the exact StrictMath (i.e. fdlibm) results.
> But when the Math methods are compiled, they may be intrinisfied, in
> which case they are allowed to return less exact values. A further
> complication is that the interpreter may optimize himself and either
> use  optimized assembler stubs for a function (e.g.
> StubRoutines::_dsin()) or uses leaf-calls into HotSpots internal
> C++-Implementation of the functions (e.g. SharedRuntime::dsin()).

JIT compilers should follow the same rule as Interpreter: call StubRoutines::_dsin or SharedRuntime::dsin.

>
> So what does "strict reproducibility is not required" for Math
> functions actually mean? Is it OK for a program like this:
>
> while(true) {
>   if (Math.FUNC(val) == XXX) System.out.println("YES");
>   else System.out.println("NO");
> }
>
> to print both, "YES" and "NO"?

No, we try to avoid this. During application one run the answer should be the same regardless how frequent a method is 
executed (JITed or not). But the result does not necessary need to be the same when an application run with different 
flags (InlineIntrinsics).

This is how I understand it.

We had a lot of bugs (for pow() especially) when results were inconsistent during run until we start using the same code 
in Interpreter and JITed code.

Regards,
Vladimir

>
> Thank you and best regards,
> Volker
>
>
> On Wed, Nov 30, 2016 at 2:34 AM, Vladimir Kozlov
> <vladimir.kozlov at oracle.com> wrote:
>> Thank you, Vivek
>>
>> I will sponsor it.
>>
>> Do you think it is hard to fix stubs code even in some next release?
>>
>> Thanks,
>> Vladimir
>>
>>
>> On 11/29/16 5:26 PM, Deshpande, Vivek R wrote:
>>>
>>> Hi
>>>
>>>
>>>
>>> I have bug fix  for avx512 8170430.
>>>
>>> http://cr.openjdk.java.net/~vdeshpande/8170430/webrev.00/
>>>
>>> I have also updated the JBS entry.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8170430
>>>
>>> I have tested it with other libm stubs too along with pow.
>>>
>>> Would you please review and sponsor it.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Vivek
>>>
>>>
>>