RFR: 8265917: Different values computed by C2 and interpreter/C1 for Math.pow(x, 2.0) on x86_32
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.
> Best regards,
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.
More information about the hotspot-compiler-dev