[aarch64-port-dev ] hg: aarch64-port/jdk8/hotspot: 2 new changesets
Andrew Dinn
adinn at redhat.com
Mon Nov 11 07:20:27 PST 2013
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
-----------
More information about the aarch64-port-dev
mailing list