RFR (S): Failure after windows compiler upgrade

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
> 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



More information about the hotspot-dev mailing list