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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So I wonder about:
--- gcc/config/i386/i386-expand.cc.jj   2023-01-04 10:45:49.978883731 +0100
+++ gcc/config/i386/i386-expand.cc      2023-01-05 18:22:40.228518935 +0100
@@ -3271,10 +3271,12 @@ ix86_expand_int_movcc (rtx operands[])
            {
              negate_cc_compare_p = true;
              std::swap (ct, cf);
-             code = EQ;
            }
          else if (code == EQ && op1 == const0_rtx && cf == -1)
-           negate_cc_compare_p = true;
+           {
+             negate_cc_compare_p = true;
+             code = NE;
+           }
        }

       diff = ct - cf;
@@ -3319,11 +3321,7 @@ ix86_expand_int_movcc (rtx operands[])

              /* To simplify rest of code, restrict to the GEU case.  */
              if (compare_code == LTU)
-               {
-                 std::swap (ct, cf);
-                 compare_code = reverse_condition (compare_code);
-                 code = reverse_condition (code);
-               }
+               std::swap (ct, cf);
              else
                {
                  if (fpcmp)
@@ -3333,6 +3331,10 @@ ix86_expand_int_movcc (rtx operands[])
                  else
                    PUT_CODE (compare_op,
                              reverse_condition (GET_CODE (compare_op)));
+                 if (SCALAR_FLOAT_MODE_P (GET_MODE (op0)))
+                   code = reverse_condition_maybe_unordered (code);
+                 else
+                   code = reverse_condition (code);
                }
              diff = ct - cf;

but am not very sure about that, especially the floating point stuff, e.g.
whether
for -ffast-math it shouldn't actually be reverse_condition (and not add any
REG_EQUAL note if code is UNKNOWN?).

Reply via email to