[aarch64-port-dev ] hg: aarch64-port/jdk8/hotspot: 2 new changesets

[Andrew Dinn]

On 11/11/13 09:58, Andrew Dinn wrote:
> I am not 100% convinced that the FP comparison changes are working
> correctly as I am now seeing an exit with code 15 when running eclipse.
> . . .
> I will recheck these tests and also review the way the ideal code
> operates to ensure that the comparisons it expects to occur actually
> match those currently implemented.

I reran the tests and checked the Ideal code and it looks to be working
correctly. The attached test program gives the same outputs as my
current installed x86 java which seems to indicate that planted
comparisons are being followed by the correct branch logic.

n.b. the warmup loop before the calls which actually print results are
there to ensure the code is C2-compiled by the time the output is
generated. I chose the specific constants passed into test1 and test2
(0.0, 1.0 and -1.0) in an attempt to push the code generator to select
b.eq, b.le and b.ge vs b.ne, b.gt and b.lt in test1 vs test2,
respectively, based on accumulated branch taken/not taken counts.
However the generated code for both routines always includes the
following compare and branch instructions (these are emitted from a CmpD
node):

  == or !=   < or >     <= or >=

  fcmpd      fcmpd      fcmpd
  b.ne       b.le       b.lt

The same branch comparison is used whichever of the two related
operators is employed in the source irrespective of how the branch taken
probabilities are stacked before compilation occurs. The required
comparison is obtained by reversing the order of the operands to the
fcmpd as needed, thus ensuring that unordered results still fold into
the correct case. This happens for all F/D compares which do not have
constant operands.

What actually happens is slightly more complex than just creating the
relevant CmpD node with the desired argument order and comparison. When
parser2.cpp  sees fcmpl or fcmpg it always creates a CmpD3Node which
feeds into a CmpINode, picking an argument order which folds unordered
into the desired case. Later on CmpINode::Ideal checks whether the value
against which the result of the CmpD3Node is being tested is 0 or above.
If so it replaces the CmpD3Node/CmpINode pair with a CmpD which will
also fold unordered into the correct case. Flipping of a compare node's
comparison arguments is carefully avoided at various points in the opto
code when the comparison condition is fed by a CmpD/F nodes precisely
because of the possibility of it rerouting the unordered case.

The only other places CmpD nodes get created (other than
CmpINode::Ideal) are in file library_call.cpp e.g. for
vmIntrinsics::_doubleToLongBits

    Node *cmpisnan = _gvn.transform(new (C) CmpDNode(arg, arg));
    // Build the boolean node
    Node *bolisnan = _gvn.transform(new (C) BoolNode(cmpisnan,
BoolTest::ne));

Looking through these cases they all appear to be created in canonical
form i.e. with a following compare that uses let or lt or else uses and
eq but can be safely flipped to ne (since flipping eq to ne still routes
unordered to the correct case).

So, I am not sure what is causing the eclipse problem but I don't think
it is the FP comparison per se. I will try to debug the eclipse run to
see at what point it decides an exit is required.

regards,


Andrew Dinn
-----------