RFR (S): Failure after windows compiler upgrade

David Holmes david.holmes at oracle.com
Tue Apr 28 05:20:18 UTC 2015


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:

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

So I'm wondering if:
a) we can fix this in the source code?; or
b) we can fix this by adding the flag only for specific files?; or
c) we can fix this by modifying the FP control word to give SSE and x87 
the same settings?

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?

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

Thanks,
David


More information about the hotspot-dev mailing list