[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

["hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #26 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Uroš Bizjak from comment #24)
> (In reply to Hongtao.liu from comment #23)
> > looking at i386.c put_condition_code used by *setcc_qi, it looks like (EQ
> > (reg:CCCmode FLAG_REG) (const_int 0)) means get carry flag.
> > Not (LTU: (REG:CCCmode FLAGS_REG) (const_int 0)).
> > Now I got more confused.
> 
> CCCmode means that single flag is tested, it uses EQ and NE, so "c" and "nc"
> suffix is emitted. When CCmode is used, LTU/GEU operation on CCmode flags
> reg produces "b" and "nb" suffix, which decodes to exactly the same assembly
> as "c" and "nc" suffixes.
> 
> However, it looks that somewhere LTU/GEU is also generated with CCCmode
> flags reg, and some fixup was introduced to put_condition_code to "fix" this
> inconsistency. If LTU/GEU is valid only for CCmode, then the producers of
> invalid RTX should be fixed.

EQ and NE are only used to set FLAGS_REG in CCCmode from 2 integer operands.
LTU/GEU are only used to check FLAGS_REG against constant 0.  This is very
consistent.  simplify_const_relational_operation has

 /* We can't simplify MODE_CC values since we don't know what the
     actual comparison is.  */
  if (GET_MODE_CLASS (GET_MODE (op0)) == MODE_CC)
    return 0;

In case of the comparison in CCCmode with constant op0 and op1, it should
let the backend perform the actual comparison.