RFR: 8265917: Different values computed by C2 and interpreter/C1 for Math.pow(x, 2.0) on x86_32

Vladimir Kozlov kvn at openjdk.java.net
Sun Apr 25 18:11:51 UTC 2021

On Sun, 25 Apr 2021 11:39:43 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> C2 may produce different results for Math.pow(x, 2.0) compared with interpreter/C1 on x86_32.
> E.g., for Math.pow(1.0 / 2047, 2.0):
> interpreter: 2.38651580386563E-7 
>          C2: 2.3865158038656307E-7
> The reason is that C2 will replace Math.pow(x, 2.0) with x*x.
> However, there is no such optimization for interpreter/C1 on x86_32.
> The fix just disables C2's opt for Math.pow(x, 2.0) on x86_32 since nobody (or very few people) would run x86_32.
> And we don't have a plan to implement such opt on x86_32.
> Another reason to fix this bug is that we need this patch to extend C2's opt for Math.pow(x, 0.5) on other platforms.
> Thanks.
> Best regards,
> Jie

I think you should fix 32-bit version of `dpow` stub because 64-bit stub has this optimization:

Also add `pow(x, 0.5)` as well.

C `dpow` code in VM has this optimization which works in 32- and in 64-bit when stub is not used (for example, on other platforms):

Java lib code also has this optimization:

Only 32-bit x86 stub is missing it:

The stub is generated only on x86:

$ grep -r StubRoutines::_dpow src/hotspot/cpu/
src/hotspot/cpu//x86/stubGenerator_x86_64.cpp:        StubRoutines::_dpow = generate_libmPow();
src/hotspot/cpu//x86/stubGenerator_x86_32.cpp:        StubRoutines::_dpow = generate_libmPow();

I suggest to fix it to be consistent with the rest of VM and Java lib code.


PR: https://git.openjdk.java.net/jdk/pull/3677

More information about the hotspot-compiler-dev mailing list