RFR (S): Failure after windows compiler upgrade (original) (raw)

Nils Eliasson nils.eliasson at oracle.com
Tue Apr 28 07:15:52 UTC 2015

Hi David,

On 2015-04-28 07:20, David Holmes wrote:

Hi Nils,

On 28/04/2015 7:07 AM, Kim Barrett wrote: On Apr 27, 2015, at 10:10 AM, Nils Eliasson <nils.eliasson at oracle.com> wrote:

A drawback is that this option also prevents any usage of SSE on the i586 platform. That could be a pretty severe drawback. For example, I’ve been working on some GC performance optimizations that can take advantage of SSE when available. I think this change would mean that the relevant code would require compile-time disable and could not use a runtime configuration test (which would succeed and permit SSE usage on anything other than low end embedded or very ancient hardware). I agree with Kim, this seems an extreme solution for a very specific problem (seems like the FP equivalent of compiling for i486 rather than i686 :( ). Where is the code that gets compiled to use the ltod3 ? The VS docs on this flag allude to problems using SEE instructions due to the mix of precision that can result, and that it can be avoided by intermediate assignments:

A cast of a long to a float. In any place calling l2f() for example. In happens regardless of optimization level.

The problem with vs2013 is that it emits an intermediate assignment we shouldn't have.

https://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx

So I'm wondering if: a) we can fix this in the source code?; or No. b) we can fix this by adding the flag only for specific files?; or

Yes but I haven't seen any preparations for that in our makefiles. It would be a bit fragile solution.

c) we can fix this by modifying the FP control word to give SSE and x87 the same settings?

No, it is the choice of instructions that is wrong. They explicitly cast the long to a double first and then to the float.

Also we have the problem reported in https://bugs.openjdk.java.net/browse/JDK-8015396 regarding unexpected NaNs. Is it related to the same underlying problem of using SSE/SSE2 instead of x87, or by mixing them?

That is a separate problem.

I'd accept the current fix as a temporary workaround to get the tests passing again. Thanks, David

ok,

Thanks, Nils

More information about the hotspot-dev mailing list