[Bug rtl-optimization/98212] [10/11 Regression] X86 unoptimal code for float equallity comparison followed by jump

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98212

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
As for f2, only the case of a == b when the jump is predicted unlikely looks
weird, e.g. take:
void foo (void);

void
bar (float a, float b)
{
  if (__builtin_expect (a != b, 1))
    foo ();
}

void
baz (float a, float b)
{
  if (__builtin_expect (a == b, 1))
    foo ();
}

void
qux (float a, float b)
{
  if (__builtin_expect (a != b, 0))
    foo ();
}

void
corge (float a, float b)
{
  if (__builtin_expect (a == b, 0))
    foo ();
}

bar:    ucomiss %xmm1, %xmm0
        jp      .L4
        je      .L1
.L4:    jmp     foo
.L1:    ret
baz:    ucomiss %xmm1, %xmm0
        jp      .L6
        jne     .L6
        jmp     foo
.L6:    ret
qux:    ucomiss %xmm1, %xmm0
        jp      .L13
        jne     .L13
        ret
.L13:   jmp     foo
corge:  ucomiss %xmm1, %xmm0
        jnp     .L18
.L14:   ret
.L18:   jne     .L14
        jmp     foo
I guess I need to debug the branch probabilities in that case, we should
certainly predict that operands are most of the time non-NaN and thus that PF
bit will not be set in 99% of cases or so.