RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne [v3]

[Quan Anh Mai]

On Wed, 4 May 2022 23:27:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> The changes to `Float` and `Double` look good. I don't think we need additional tests, see test/jdk/java/lang/Math/IeeeRecommendedTests.java.
>> 
>> At first i thought we no longer need PR #8459 but it seems both PRs are complimentary, albeit PR #8459 has more modest performance gains for the intrinsics.
>
>> The changes to `Float` and `Double` look good. I don't think we need additional tests, see test/jdk/java/lang/Math/IeeeRecommendedTests.java.
> 
> Thank you, Paul for pointing the test. It means we need to run tier4 (which runs these tests with -Xcomp) to make sure methods are compiled by C2.

@vnkozlov  I have added comments to describe the changes in `cmpOpUCF` and the reasons behind the `cmov_regUCF2_eq` match rules. Using `expand` broke the build with `Syntax Error: :For expand in cmovI_regUCF2_eq to work, parameter declaration order in cmovI_regUCF2_ne must follow matchrule`.

@sviswa7  (x != y) ? a : b can be calculated using pseudocode as follow:

    res = (!ZF || PF) ? a : b
        = !ZF ? a : (PF ? a : b)

which can be calculated using

    cmovp  rb, ra // rb1 = PF ? ra : rb
    cmovne rb, ra // rb2 = !ZF ? ra : rb1 = !ZF ? ra : (PF ? ra : rb)

Furthermore, since `(x == y) == !(x != y)`, we have `((x == y) ? a : b) == ((x != y) ? b : a)`, which explains the implementation of `cmov_regUCF2_eq`.

@vamsi-parasa Thanks a lot for your suggestion, I have modified the PR description as you say.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8525