United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6754519 don't emit flag fixup for NaN when condition being tested doesn't need it
JDK-6754519 : don't emit flag fixup for NaN when condition being tested doesn't need it

Details
Type:
Bug
Submit Date:
2008-10-01
Status:
Resolved
Updated Date:
2010-05-10
Project Name:
JDK
Resolved Date:
2008-11-19
Component:
hotspot
OS:
solaris_9
Sub-Component:
compiler
CPU:
sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs14
Fixed Versions:
hs14 (b07)

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

Description
Java's rules for handling NaNs in floating point comparisons requires that extra fixup code be emitted for them.  Currently we do this all the time but for many fp tests the fixup code won't change the result of the comparison.  In those cases it should be eliminated.

                                    

Comments
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4d9884b01ba6
                                     
2008-10-28
EVALUATION

Because Java has rules about how unordered values are treated in
floating point comparisions we perform some complicated fixup of the
condition codes when the parity bit is set.  For some <, <=, >, and >=
tests this fixup won't change the direction the test would take so it
is unneeded.  In the cases where the fixup will have an effect we can
directly emit jumps based on the parity.  To do this we add special
condition code producers and consumers to match the cases where this
can be optimized.  The matching is somewhat complicated because we
have to take into account both the compare operation and the Bool
direction, so I had to replicate several of the condition code
consumers.  In general I did that using expand rules though in a few
cases that wasn't possible.  Since the code for these should be almost
exactly the same for 32 and 64 bit, I made a few changes to make these
portions of the ad files more similar.  I also had to extend the short
branch logic slightly since the jmpConUCF2 variants have two jumps in
them which makes the reach of the branches slightly less.

Additionally I fixed a bug in the adlc where line numbers were no
longer matching up.  I added support for format strings for condition
code so that the opto assembly actually reads like the assembly would.
Several of the new instructions have complicated opto formatting
requirements so I added support for mixing code with format strings.

tested with ctw, nsk, runthese, 32 and 64 bit with UseSSE=0 in
addition to the default.
                                     
2008-10-28



Hardware and Software, Engineered to Work Together