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

[Andrew Dinn]

Corrected typos. n.b. the test code I provided needs to be run with a
-server -Xcomp -XX:CompileCommandFile=XXX whe file XXX contains

  compileonly DoubleTest:test*
  print DoubleTest:test*

On 11/11/13 15:13, Andrew Dinn wrote:
> 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) is
> 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

condition and arguments is carefully avoided at various points in the opto

> code if 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 either uses le/lt or else uses
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
-----------