[8u] RFR(S): 8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade

[Hohensee, Paul]

Looks good.

Thanks,
Paul

-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of "Liu, Xin" <xxinliu at amazon.com>
Date: Friday, October 22, 2021 at 4:43 PM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Cc: Nils Eliasson <nils.eliasson at oracle.com>
Subject: [8u] RFR(S): 8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade

Hi,

Please review the backport of JDK-8077590 to jdk8u:
Bug: https://bugs.openjdk.java.net/browse/JDK-8077590
Webrev: https://cr.openjdk.java.net/~xliu/8077590/webrev/
Original Review Thread:
https://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/018258.html

This patch will append the MSVC flag '/arch:IA32' to cl.exe on Windows
x86. "/arch:IA32 Specifies no enhanced instructions and also specifies
x87 for floating-point calculations."
https://docs.microsoft.com/en-us/cpp/build/reference/arch-x86?view=msvc-160

I can't access JDK-8077590, but I think it is close to the C2 bug we
encounter on Windows x86. After we upgrade our toolchain from VS2010 to
VS2013 on Windows, it starts using XMM registers in codegen. Currently,
generate_d2i_wrapper(), which is only used for x86_32, doesn't save XMM
registers. C2 UseFPUForSpilling may spill General-purpose
Registers(GPRs) to XMM registers. Therefore, native functions such as
SharedRuntime::d2l may accidentally clobber XMM registers used by RA
spilling. More details are in JDK-8275565. Refraining cl.exe from using
XMM registers can solve problem.

Besides the register clobbering issue, I guess there is another floating
point precision issue described in JDK-8077590. I think it's a good idea
to keep using x87 on windows x86. Is it possible the original author of
this patch unlocks JDK-8077590 so I can follow the 8u backport label
process?

Risk:
This patch only affects the build on Windows x86. The recommended
toolchain for jdk8u is Visual Studio 2010. This patch ensures that
vs2013 has consistent behavior with vs2010 in terms of FP codegen. Thus,
I think the risk is low.  We have verified this patch using our pipeline.

thanks,
--lx