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