[Bug tree-optimization/107172] New: wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu

[Bug tree-optimization/107172] New: wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch]

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

            Bug ID: 107172
           Summary: wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This seems to be a recent regression.

Compiler Explorer: https://godbolt.org/z/xj7ods8Pv

[596] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221006 (experimental) [master r13-3101-g966010b2eb4] (GCC) 
[597] % 
[597] % gcctk -O1 small.c; ./a.out
[598] % 
[598] % gcctk -O1 -ftree-vrp small.c
[599] % ./a.out
Segmentation fault
[600] % 
[600] % cat small.c
int a, *b, c, d;
int main() {
  long e = 1;
  int f = a = 1;
 L1:
  if (a)
    a = 2;
  int h = e = ~e;
  c = -1;
  if (e >= a)
    goto L2;
  if (c > a)
    goto L1;
  if (a)
    f = -1;
 L2:
  d = (-f + d) & h;
  if (d)
    (*b)++;
  return 0;
}

[Bug tree-optimization/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|wrong code with "-O1        |[13 Regression] wrong code
                   |-ftree-vrp" on              |with "-O1 -ftree-vrp" on
                   |x86_64-linux-gnu            |x86_64-linux-gnu
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-10-06
     Ever confirmed|0                           |1
   Target Milestone|---                         |13.0

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed. Reduced a little bit more:
```
int a, c, d;
int main() {
  long e = 1;
  int f = a = 1;
 L1:
  if (a)
    a = 2;
  int h = e = ~e;
  c = -1;
  if (e >= a)
    goto L2;
  if (-1 > a)
    goto L1;
  if (a)
    f = -1;
 L2:
  d = (-f + d) & h;
  if (d)
    __builtin_abort();
  return 0;
}
```
Note the store for c is important there. I suspect otherwise the load to e is
figured out and does the correct thing.

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

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org
            Summary|[13 Regression] wrong code  |[13 Regression] wrong code
                   |with "-O1 -ftree-vrp" on    |with "-O1 -ftree-vrp" on
                   |x86_64-linux-gnu            |x86_64-linux-gnu since
                   |                            |r13-1268-g8c99e307b20c502e

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r13-1268-g8c99e307b20c502e.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

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

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #2)
> Started with r13-1268-g8c99e307b20c502e.

Disabling DOM with -fno-tree-dominator-opts still causes the crash, so it's not
this patch that caused the problem.  Furthermore, the IL at the *.optimized
dump looks fine, so this may be an RTL problem.  I also disabled VRP's
exporting of global ranges to make sure it's not RTL-land making decisions
based on global SSA ranges.

Also, the revision before r13-1268-g8c99e307b20c502e also fails with
-fno-tree-dominator-opts -O1 -ftree-vrp.

I tried bisecting this further with -fno-tree-dominator-opts -O1 -ftree-vrp,
and ran into:

commit f1652e3343b1ec47035370801d9b9aca1f8b613f
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Mon May 30 21:26:37 2022 +0100

    PR rtl-optimization/101617: Use neg/sbb in ix86_expand_int_movcc.

    This patch resolves PR rtl-optimization/101617 where we should generate
    the exact same code for (X ? -1 : 1) as we do for ((X ? -1 : 0) | 1).
    The cause of the current difference on x86_64 is actually in
    ix86_expand_int_movcc that doesn't know that negl;sbbl can be used
    to create a -1/0 result depending on whether the input is zero/nonzero.

[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]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com,
                   |                            |ubizjak at gmail dot com

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
There are:

(insn 6 5 17 2 (set (reg:SI 87 [ a_lsm.8 ])
        (const_int 2 [0x2])) "x.c":7:7 83 {*movsi_internal}
     (nil))
...
(insn 62 59 63 2 (parallel [
            (set (reg:CCC 17 flags)
                (ne:CCC (reg:SI 87 [ a_lsm.8 ])
                    (const_int 0 [0])))
            (set (reg:SI 96) 
                (neg:SI (reg:SI 87 [ a_lsm.8 ])))
        ]) "x.c":4:7 680 {*negsi_ccc_1}
     (expr_list:REG_DEAD (reg:SI 87 [ a_lsm.8 ])
        (expr_list:REG_UNUSED (reg:SI 96) 
            (nil))))
(insn 63 62 64 2 (parallel [
            (set (reg:SI 97) 
                (neg:SI (ltu:SI (reg:CCC 17 flags)
                        (const_int 0 [0]))))
            (clobber (reg:CC 17 flags))
        ]) "x.c":4:7 1258 {*x86_movsicc_0_m1_neg}
     (expr_list:REG_DEAD (reg:CCC 17 flags)
        (expr_list:REG_UNUSED (reg:CC 17 flags)
            (nil))))

Since r87 == 2, combine knows (reg:CCC 17 flags) == 1 and optimizes

(ltu:SI (reg:CCC 17 flags)
    (const_int 0 [0]))

as

(ltu:SI (const_int 1 [1])
    (const_int 0 [0]))

to 0.

[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]

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

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
i386 needs to change

(ltu:SI (const_int 1 [1])
    (const_int 0 [0]))

to

(ne:SI (const_int 1 [1])
    (const_int 0 [0]))

when checking the carry flag.  But the mode info isn't passed to
TARGET_CANONICALIZE_COMPARISON.

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

[roger at nextmovesoftware dot com]

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

--- Comment #6 from Roger Sayle <roger at nextmovesoftware dot com> ---
This sounds related to the discussion/patch originally proposed at
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598040.html
and then revised (based on reviewer comments) at
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598835.html

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

[segher at gcc dot gnu.org]

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |segher at gcc dot gnu.org

--- Comment #7 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Please show the (relevant part of) output of -fdump-rtl-combine-all ?  At least
those parts where it decided (ltu:SI (const_int 1) (const_int 0)) is valid (it
isn't) and where optimising that to (const_int 0) is valid (it isn't).

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

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Bah, scratch that last part, of course it is valid (I thought this was using 0
in a MODE_CC but I just cannot read).

[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]

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

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Segher Boessenkool from comment #7)
> Please show the (relevant part of) output of -fdump-rtl-combine-all ?  At
> least
> those parts where it decided (ltu:SI (const_int 1) (const_int 0)) is valid
> (it
> isn't) and where optimising that to (const_int 0) is valid (it isn't).

Trying 6, 62 -> 63:
    6: r87:SI=0x2
   62: {flags:CCC=r87:SI!=0;r96:SI=-r87:SI;}
      REG_DEAD r87:SI
      REG_UNUSED r96:SI
   63: {r97:SI=-ltu(flags:CCC,0);clobber flags:CC;}
      REG_DEAD flags:CCC
      REG_UNUSED flags:CC
Failed to match this instruction:
(parallel [
        (set (reg:SI 97)
            (const_int 0 [0]))
        (clobber (reg:CC 17 flags))
        (set (reg:SI 96)
            (const_int -2 [0xfffffffffffffffe]))
    ])
Failed to match this instruction:
(parallel [
        (set (reg:SI 97)
            (const_int 0 [0]))
        (set (reg:SI 96)
            (const_int -2 [0xfffffffffffffffe]))
    ])
Successfully matched this instruction:
(set (reg:SI 96)
    (const_int -2 [0xfffffffffffffffe]))
Successfully matched this instruction:
(set (reg:SI 97)
    (const_int 0 [0]))
allowing combination of insns 6, 62 and 63
original costs 4 + 0 + 8 = 0
replacement costs 4 + 4 = 8
deferring deletion of insn with uid = 62.
deferring deletion of insn with uid = 6.
modifying insn i2    62: r96:SI=0xfffffffffffffffe
deferring rescan insn with uid = 62.
modifying insn i3    63: r97:SI=0
deferring rescan insn with uid = 63.

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

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool <segher at gcc dot gnu.org> ---
The input to combine has

(insn 49 10 50 2 (parallel [
            (set (reg:CCC 17 flags)
                (ne:CCC (reg:SI 82 [ a.1_2 ])
                    (const_int 0 [0])))
            (set (reg:SI 92)
                (neg:SI (reg:SI 82 [ a.1_2 ])))
        ]) "107172.c":4:10 680 {*negsi_ccc_1}
     (expr_list:REG_DEAD (reg:SI 82 [ a.1_2 ])
        (expr_list:REG_UNUSED (reg:SI 92)
            (nil))))
(insn 50 49 51 2 (parallel [
            (set (reg:SI 93)
                (neg:SI (ltu:SI (reg:CCC 17 flags)
                        (const_int 0 [0]))))
            (clobber (reg:CC 17 flags))
        ]) "107172.c":4:10 1258 {*x86_movsicc_0_m1_neg}
     (expr_list:REG_DEAD (reg:CCC 17 flags)
        (expr_list:REG_UNUSED (reg:CC 17 flags)
            (nil))))

This is incorrect already: insn 49 has to do a cmp, not a ne, for it to be
valid.  It was created by the ce1 pass.

[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]

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

--- Comment #11 from H.J. Lu <hjl.tools at gmail dot com> ---
Assuming (reg:CCC 17 flags) is set to 1 by compare properly, how should

(insn 50 49 51 2 (parallel [
            (set (reg:SI 93)
                (neg:SI (ltu:SI (reg:CCC 17 flags)
                        (const_int 0 [0]))))
            (clobber (reg:CC 17 flags))
        ]) "107172.c":4:10 1258 {*x86_movsicc_0_m1_neg}
     (expr_list:REG_DEAD (reg:CCC 17 flags)
        (expr_list:REG_UNUSED (reg:CC 17 flags)
            (nil))))

work?

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

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #11)
> Assuming (reg:CCC 17 flags) is set to 1 by compare properly, how should

A MODE_CC RTL reg is never set to "1".  It is set to the result of a
comparison,
instead.  The semantics of a consumer of a MODE_CC depends on the producer.

> (insn 50 49 51 2 (parallel [
>             (set (reg:SI 93)
>                 (neg:SI (ltu:SI (reg:CCC 17 flags)
>                         (const_int 0 [0]))))
>             (clobber (reg:CC 17 flags))
>         ]) "107172.c":4:10 1258 {*x86_movsicc_0_m1_neg}
>      (expr_list:REG_DEAD (reg:CCC 17 flags)
>         (expr_list:REG_UNUSED (reg:CC 17 flags)
>             (nil))))
> 
> work?

The semantics of
  (ltu:SI (reg:CCC 17) (const_int 0))
is: the result of "ltu" of the producer of this reg 17, taken from 17 as mode
CCC (which means only the carry output is valid), and that result as a SImode
(which then depends on what STORE_FLAG_VALUE is for your target -- 1 or -1 for
most targets, but other values are more complicated).

It never means "1".  It never means "0".  Never.

To determine the semantics of this piece of RTL you need to see the setter(s)
of reg 17 feeding this use.  In this case, the setter was
  (set (reg:CCC 17)
       (ne:CCC (reg:SI 82)
               (const_int 0 [0])))
which has no meaning for a use that uses "ltu".

[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]

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

--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Segher Boessenkool from comment #12)
> 
> To determine the semantics of this piece of RTL you need to see the setter(s)
> of reg 17 feeding this use.  In this case, the setter was
>   (set (reg:CCC 17)
>        (ne:CCC (reg:SI 82)
>                (const_int 0 [0])))
> which has no meaning for a use that uses "ltu".

What should a valid setter look like?  It should set reg 17 in CCC mode if
reg 82 in SI mode isn't 0.

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

[segher at gcc dot gnu.org]

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

--- Comment #14 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #13)
> (In reply to Segher Boessenkool from comment #12)
> > 
> > To determine the semantics of this piece of RTL you need to see the setter(s)
> > of reg 17 feeding this use.  In this case, the setter was
> >   (set (reg:CCC 17)
> >        (ne:CCC (reg:SI 82)
> >                (const_int 0 [0])))
> > which has no meaning for a use that uses "ltu".
> 
> What should a valid setter look like?  It should set reg 17 in CCC mode if
> reg 82 in SI mode isn't 0.

CCCmode can only represent the result of a comparison, like any other MODE_CC
thing.  The i386 CCCmode means only the carry bit can be used for this, so you
beed to do an unsigned comparison against (const_int 1).  This will end up with
the opposite polarity of what you said I guess, you need "geu" instead?

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

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roger at nextmovesoftware dot com

--- Comment #15 from Roger Sayle <roger at nextmovesoftware dot com> ---
Hi HJ (and Segher),
The i386's *negsi_ccc_1 pattern fully models the flags setting behaviour of the
x86's neg instruction.  neg %eax, in addition to setting %eax to -%eax, will
clear the carry flag if %eax is zero, and set it for all other values of %eax. 
Hence, this pattern is a useful mechanism for setting the carry flag to a known
value from a scalar integer register.  For example, it's used in the expansion
of __builtin_add_with_carry (sp?).

The *x86_movsicc_0_m1_neg instruction does the reverse.  The sbc %eax,%eax
instruction (subtract with carry) will place the value 0 in %eax if the carry
flag is clear, and the value -1 in %eax if the carry flag is set (independent
of whatever value was in %eax before the instruction).

Understanding these patterns is perhaps a little easier with a little more
context.  For example,
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598058.html describes
efforts to add support for x86's stc (set carry flag) and clc (clear carry
flag) instructions.  I've a similar patch for "cmc" (complement carry flag) but
all of these are blocked by the simplify-rtx issue
underlying PR 107172, that MODE_CC requires special care and/or backend
specific support to interpret.

Yes, a COMPARE rtx can be used to set various flags on x86, but many other
operations also legitimately set and/or use MODE_CC, often in a parallel with
the primary operation.

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

[segher at gcc dot gnu.org]

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

--- Comment #16 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Hi Roger,

(In reply to Roger Sayle from comment #15)
> Yes, a COMPARE rtx can be used to set various flags on x86, but many other
> operations also legitimately set and/or use MODE_CC, often in a parallel
> with the primary operation.

*Any* MODE_CC setter sets the flags as-if from a compare.  This is what
MODE_CC *is*.

Setting something as ne:CC and then using it as somethingelse:CC has no
defined meaning.

[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]

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

--- Comment #17 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Segher Boessenkool from comment #14)
> (In reply to H.J. Lu from comment #13)
> > (In reply to Segher Boessenkool from comment #12)
> > > 
> > > To determine the semantics of this piece of RTL you need to see the setter(s)
> > > of reg 17 feeding this use.  In this case, the setter was
> > >   (set (reg:CCC 17)
> > >        (ne:CCC (reg:SI 82)
> > >                (const_int 0 [0])))
> > > which has no meaning for a use that uses "ltu".
> > 
> > What should a valid setter look like?  It should set reg 17 in CCC mode if
> > reg 82 in SI mode isn't 0.
> 
> CCCmode can only represent the result of a comparison, like any other MODE_CC
> thing.  The i386 CCCmode means only the carry bit can be used for this, so
> you
> beed to do an unsigned comparison against (const_int 1).  This will end up
> with
> the opposite polarity of what you said I guess, you need "geu" instead?

Since it checks if the input register is 0, compare against (const_int 1)
won't work here.

[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]

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

--- Comment #18 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Segher Boessenkool from comment #16)
> Hi Roger,
> 
> (In reply to Roger Sayle from comment #15)
> > Yes, a COMPARE rtx can be used to set various flags on x86, but many other
> > operations also legitimately set and/or use MODE_CC, often in a parallel
> > with the primary operation.
> 
> *Any* MODE_CC setter sets the flags as-if from a compare.  This is what
> MODE_CC *is*.
> 
> Setting something as ne:CC and then using it as somethingelse:CC has no
> defined meaning.

This

(parallel [
            (set (reg:SI 97) 
                (neg:SI (ltu:SI (reg:CCC 17 flags)
                        (const_int 0 [0]))))
            (clobber (reg:CC 17 flags))
        ])

still won't work correctly if reg:CCC 17 flags is set by a compare of
2 known values.

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

[crazylht at gmail dot com]

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

--- Comment #19 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to H.J. Lu from comment #18)
> (In reply to Segher Boessenkool from comment #16)
> > Hi Roger,
> > 
> > (In reply to Roger Sayle from comment #15)
> > > Yes, a COMPARE rtx can be used to set various flags on x86, but many other
> > > operations also legitimately set and/or use MODE_CC, often in a parallel
> > > with the primary operation.
> > 
> > *Any* MODE_CC setter sets the flags as-if from a compare.  This is what
> > MODE_CC *is*.
> > 
> > Setting something as ne:CC and then using it as somethingelse:CC has no
> > defined meaning.
> 
> This
> 
> (parallel [
>             (set (reg:SI 97) 
>                 (neg:SI (ltu:SI (reg:CCC 17 flags)
>                         (const_int 0 [0]))))
>             (clobber (reg:CC 17 flags))
>         ])
> 
> still won't work correctly if reg:CCC 17 flags is set by a compare of
> 2 known values.

I guess Segher means it should be NE instead of LTU in the
x86_mov<mode>cc_0_m1_neg, since the setters is NE to const 0.

 (ne:CCC (reg:SI 87 [ a_lsm.8 ])
                    (const_int 0 [0])))

 (define_expand "x86_mov<mode>cc_0_m1_neg"
   [(parallel
     [(set (match_operand:SWI48 0 "register_operand")
-         (neg:SWI48 (ltu:SWI48 (reg:CCC FLAGS_REG) (const_int 0))))
+         (neg:SWI48 (ne:SWI48 (reg:CCC FLAGS_REG) (const_int 0))))
      (clobber (reg:CC FLAGS_REG))])])

It can pass the PR, but failed pr101617.c, the f1 case.

generate:
        testl   %edi, %edi
        movl    $1, %edx
        movl    $-1, %eax
        cmove   %edx, %eax

origin:
        negl    %edi
        sbbl    %eax, %eax
        orl     $1, %eax

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

[crazylht at gmail dot com]

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

--- Comment #20 from Hongtao.liu <crazylht at gmail dot com> ---
> generate:
>         testl   %edi, %edi
>         movl    $1, %edx
>         movl    $-1, %eax
>         cmove   %edx, %eax
> 
> origin:
>         negl    %edi
>         sbbl    %eax, %eax
>         orl     $1, %eax

It now go through *if-conversion succeeded through noce_try_cmove_arith*
instead of original *if-conversion succeeded through noce_try_cmove*.

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

[segher at gcc dot gnu.org]

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

--- Comment #21 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Hongtao.liu from comment #19)
> (In reply to H.J. Lu from comment #18)
> > (In reply to Segher Boessenkool from comment #16)
> > > Hi Roger,
> > > 
> > > (In reply to Roger Sayle from comment #15)
> > > > Yes, a COMPARE rtx can be used to set various flags on x86, but many other
> > > > operations also legitimately set and/or use MODE_CC, often in a parallel
> > > > with the primary operation.
> > > 
> > > *Any* MODE_CC setter sets the flags as-if from a compare.  This is what
> > > MODE_CC *is*.
> > > 
> > > Setting something as ne:CC and then using it as somethingelse:CC has no
> > > defined meaning.
> > 
> > This
> > 
> > (parallel [
> >             (set (reg:SI 97) 
> >                 (neg:SI (ltu:SI (reg:CCC 17 flags)
> >                         (const_int 0 [0]))))
> >             (clobber (reg:CC 17 flags))
> >         ])
> > 
> > still won't work correctly if reg:CCC 17 flags is set by a compare of
> > 2 known values.
> 
> I guess Segher means it should be NE instead of LTU in the
> x86_mov<mode>cc_0_m1_neg, since the setters is NE to const 0.

Yes.

>  (ne:CCC (reg:SI 87 [ a_lsm.8 ])
>                     (const_int 0 [0])))
> 
>  (define_expand "x86_mov<mode>cc_0_m1_neg"
>    [(parallel
>      [(set (match_operand:SWI48 0 "register_operand")
> -         (neg:SWI48 (ltu:SWI48 (reg:CCC FLAGS_REG) (const_int 0))))
> +         (neg:SWI48 (ne:SWI48 (reg:CCC FLAGS_REG) (const_int 0))))
>       (clobber (reg:CC FLAGS_REG))])])
> 
> It can pass the PR, but failed pr101617.c, the f1 case.
> 
> generate:
>         testl   %edi, %edi
>         movl    $1, %edx
>         movl    $-1, %eax
>         cmove   %edx, %eax
> 
> origin:
>         negl    %edi
>         sbbl    %eax, %eax
>         orl     $1, %eax

And this is why using a relation (e.g. ltu, an RTX_COMPARE) instead of a
compare (an RTX_BIN_ARITH) as setter cannot work.  The setter and the getter
are modified independently by very many parts of the compiler, and then
everything falls apart.

The only valid things on the RHS of a MODE_CC set are a reg, a compare, or
an unspec.  Everything else is undefined and problematical as well.

[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]

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

--- Comment #22 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Segher Boessenkool from comment #21)
> (In reply to Hongtao.liu from comment #19)
> > (In reply to H.J. Lu from comment #18)
> > > (In reply to Segher Boessenkool from comment #16)
> > > > Hi Roger,
> > > > 
> > > > (In reply to Roger Sayle from comment #15)
> > > > > Yes, a COMPARE rtx can be used to set various flags on x86, but many other
> > > > > operations also legitimately set and/or use MODE_CC, often in a parallel
> > > > > with the primary operation.
> > > > 
> > > > *Any* MODE_CC setter sets the flags as-if from a compare.  This is what
> > > > MODE_CC *is*.
> > > > 
> > > > Setting something as ne:CC and then using it as somethingelse:CC has no
> > > > defined meaning.
> > > 
> > > This
> > > 
> > > (parallel [
> > >             (set (reg:SI 97) 
> > >                 (neg:SI (ltu:SI (reg:CCC 17 flags)
> > >                         (const_int 0 [0]))))
> > >             (clobber (reg:CC 17 flags))
> > >         ])
> > > 
> > > still won't work correctly if reg:CCC 17 flags is set by a compare of
> > > 2 known values.
> > 
> > I guess Segher means it should be NE instead of LTU in the
> > x86_mov<mode>cc_0_m1_neg, since the setters is NE to const 0.
> 
> Yes.

So the issue is with the consumer:

(insn 50 49 51 2 (parallel [
            (set (reg:SI 93)
                (neg:SI (ltu:SI (reg:CCC 17 flags)
                        (const_int 0 [0]))))
            (clobber (reg:CC 17 flags))
        ]) "107172.c":4:10 1258 {*x86_movsicc_0_m1_neg}
     (expr_list:REG_DEAD (reg:CCC 17 flags)
        (expr_list:REG_UNUSED (reg:CC 17 flags)
            (nil))))

There are many similar patterns in different backends.  They work as long as
the flags register isn't a known constant since simplify-rtx.cc leaves them
alone.  They become a problem only when the flags register is a known constant.

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

[crazylht at gmail dot com]

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

--- Comment #23 from Hongtao.liu <crazylht at gmail dot com> ---
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.

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

[ubizjak at gmail dot com]

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

--- Comment #24 from Uroš Bizjak <ubizjak at gmail dot com> ---
(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.

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

[crazylht at gmail dot com]

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

--- Comment #25 from Hongtao.liu <crazylht 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.

grep -e ltu -e geu *.md, it looks like most places use CCmode for LTU, only
below cases use CCCmode, maybe we should use CCmode for all of those and "fix"
put_condition_code?

------------cut CCCmode-----------------------
i386.md:               (ltu (reg:CCC FLAGS_REG) (const_int 0))
i386.md:        (compare:CCC (neg:QI (geu:QI (reg:CC_CCC FLAGS_REG) (const_int
0)))
i386.md:                     (ltu:QI (reg:CC_CCC FLAGS_REG) (const_int 0))))]
i386.md:          (neg:SWI48 (ltu:SWI48 (reg:CCC FLAGS_REG) (const_int 0))))
i386.md:        (neg:SWI (ltu:SWI (reg:CCC FLAGS_REG) (const_int 0))))])

------------cut ends---------------------------

------------cut CCmode---------------
i386.md:                       (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))
i386.md:                       (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))
i386.md:                         (ltu:<DWI> (reg:CC FLAGS_REG) (const_int 0))
i386.md:                           (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))
i386.md:                       (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))
i386.md:                         (ltu:<DWI> (reg:CC FLAGS_REG) (const_int 0))
i386.md:                           (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))
i386.md:                       (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))
i386.md:                       (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0)))
i386.md:                       (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0)))
i386.md:                         (ltu:<DWI> (reg:CC FLAGS_REG) (const_int 0)))
i386.md:                           (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0)))
i386.md:                       (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0)))
i386.md:                         (ltu:<DWI> (reg:CC FLAGS_REG) (const_int 0)))
i386.md:                           (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0)))
i386.md:                       (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0)))
i386.md:               (ltu (reg:CC FLAGS_REG) (const_int 0))
i386.md:            (ltu:<DWI> (reg:CC FLAGS_REG) (const_int 0))
i386.md:            (ltu:<DWI> (reg:CC FLAGS_REG) (const_int 0))
i386.md:                      (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))]
i386.md:                           (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))
i386.md:                       (ltu:<DWI> (reg:CC FLAGS_REG) (const_int 0)))))
i386.md:                     (plus:DWIH (ltu:DWIH (reg:CC FLAGS_REG) (const_int
0))
i386.md:                     (plus:SWI (ltu:SWI (reg:CC FLAGS_REG) (const_int
0))
i386.md:                                (ltu:SWI (reg:CC FLAGS_REG) (const_int
0)))
i386.md:                   (plus:SWI (ltu:SWI (reg:CC FLAGS_REG) (const_int 0))
i386.md:                                (ltu:SWI (reg:CC FLAGS_REG) (const_int
0)))
i386.md:                                (ltu:SWI (reg:CC FLAGS_REG) (const_int
0)))
i386.md:                     (plus:SWI (ltu:SWI (reg:CC FLAGS_REG) (const_int
0))
i386.md:                                (ltu:SWI (reg:CC FLAGS_REG) (const_int
0)))
i386.md:                              (ltu:SWI (reg:CC FLAGS_REG) (const_int
0))))
i386.md:                               (ltu:SWI (reg:CC FLAGS_REG) (const_int
0))
i386.md:          (plus:DWIH (plus:DWIH (ltu:DWIH (reg:CC FLAGS_REG) (const_int
0))
i386.md:                        (ltu:SWI48 (reg:CC FLAGS_REG) (const_int 0))
i386.md:                         (ltu:SWI48 (reg:CC FLAGS_REG) (const_int 0)))
i386.md:                        (ltu:SWI48 (reg:CC FLAGS_REG) (const_int 0))
i386.md:          (if_then_else:SWI48 (ltu:SWI48 (reg:CC FLAGS_REG) (const_int
0))
i386.md:          (plus:DWIH (plus:DWIH (ltu:DWIH (reg:CC FLAGS_REG) (const_int
0))
i386.md:          (plus:DWIH (plus:DWIH (ltu:DWIH (reg:CC FLAGS_REG) (const_int
0))
i386.md:        (ltu:QI (reg:CC FLAGS_REG) (const_int 0)))
i386.md:        (ltu:QI (reg:CC FLAGS_REG) (const_int 0)))
i386.md:        (ltu:QI (reg:CC FLAGS_REG) (const_int 0)))
i386.md:        (neg:SWI48 (ltu:SWI48 (reg:CC FLAGS_REG) (const_int 0))))]
i386.md:        (neg:SWI (ltu:SWI (reg:CC FLAGS_REG) (const_int 0))))])

------------cut ends-------------

[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]

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.

[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]

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

--- Comment #27 from H.J. Lu <hjl.tools at gmail dot com> ---
Another oddity is

  (set (pc) (if_then_else
               (eq (reg:CCO FLAGS_REG) (const_int 0))
               (label_ref (match_operand 3))
               (pc)))]

CCOmode means that the overflow flag is tested.  EQ means that the flag is set
and NE
means unset.

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

[segher at gcc dot gnu.org]

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

--- Comment #28 from Segher Boessenkool <segher at gcc dot gnu.org> ---
> So the issue is with the consumer:
> 
> (insn 50 49 51 2 (parallel [
>             (set (reg:SI 93)
>                 (neg:SI (ltu:SI (reg:CCC 17 flags)
>                         (const_int 0 [0]))))
>             (clobber (reg:CC 17 flags))
>         ]) "107172.c":4:10 1258 {*x86_movsicc_0_m1_neg}
>      (expr_list:REG_DEAD (reg:CCC 17 flags)
>         (expr_list:REG_UNUSED (reg:CC 17 flags)
>             (nil))))
> 
> There are many similar patterns in different backends.  They work as long as
> the flags register isn't a known constant since simplify-rtx.cc leaves them
> alone.  They become a problem only when the flags register is a known
> constant.

Such patterns are fine.  The problem is that this consumer of MODE_CC does not
fit together with the producer of that reg 17: it only has meaning together,
that
is how this stuff works; and it has no meaning at all like this.

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

[segher at gcc dot gnu.org]

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

--- Comment #29 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(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.

(eq (reg:CCC 17) (const_int 0))  means that the comparison that did set reg 17
returned "equal".

CCCmode is just like CCmode, but *only* the carry flag is valid.

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

[segher at gcc dot gnu.org]

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

--- Comment #30 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #26)
> LTU/GEU are only used to check FLAGS_REG against constant 0.

That is not what
  (ltu (reg 17) (const_int 0))
means though?

Together with a previous
  (set (reg 17) (compare A B))

it means the result of A <= B.

There is no actual comparison with 0, that is just notation.

> 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;

And combine *does* know how to find the actual comparison, in many cases.  Some
other passes can as well, there is no magic involved, you just need to look at
other insns as well (just one really, the CC setter).

[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]

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

--- Comment #31 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Segher Boessenkool from comment #29)
> (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.
> 
> (eq (reg:CCC 17) (const_int 0))  means that the comparison that did set reg
> 17
> returned "equal".
> 

Isn't the meaning of MODE_CC comparison only known to the backend? On x86, EQ
in

  (set (pc) (if_then_else
               (eq (reg:CCO FLAGS_REG) (const_int 0))
               (label_ref (match_operand 3))
               (pc)))]

doesn't evaluate to true when (reg:CCO FLAGS_REG) is 0.  It is true when
(reg:CCO FLAGS_REG) is set.

[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]

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

--- Comment #32 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Segher Boessenkool from comment #30)
> (In reply to H.J. Lu from comment #26)
> > LTU/GEU are only used to check FLAGS_REG against constant 0.
> 
> That is not what
>   (ltu (reg 17) (const_int 0))
> means though?
> 
> Together with a previous
>   (set (reg 17) (compare A B))
> 
> it means the result of A <= B.

That is correct.

> There is no actual comparison with 0, that is just notation.

True.  But simplify-rtx.cc simplifies

(ltu (reg 17) (const_int 0))

to false when reg 17 is set.

> > 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;
> 
> And combine *does* know how to find the actual comparison, in many cases. 
> Some
> other passes can as well, there is no magic involved, you just need to look
> at
> other insns as well (just one really, the CC setter).

Use the actual comparison isn't issue.  The issue is how

(ltu (reg 17) (const_int 0))

should be simplified when reg 17 is known to be set.

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

[segher at gcc dot gnu.org]

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

--- Comment #33 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #32)
> > There is no actual comparison with 0, that is just notation.
> 
> True.  But simplify-rtx.cc simplifies
> 
> (ltu (reg 17) (const_int 0))
> 
> to false when reg 17 is set.

Is set?  What does that even mean?  Is set to what?

> Use the actual comparison isn't issue.  The issue is how
> 
> (ltu (reg 17) (const_int 0))
> 
> should be simplified when reg 17 is known to be set.

You need to look at the setter.  It cannot be simplified otherwise.

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

[crazylht at gmail dot com]

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

--- Comment #34 from Hongtao.liu <crazylht at gmail dot com> ---
There's 2 similar issues in PR107273 and PR107269.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #35 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 107269 has been marked as a duplicate of this bug. ***

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

[rguenth at gcc dot gnu.org]

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

--- Comment #36 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 107273 has been marked as a duplicate of this bug. ***

[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]

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

--- Comment #37 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Segher Boessenkool from comment #33)
> (In reply to H.J. Lu from comment #32)
> > > There is no actual comparison with 0, that is just notation.
> > 
> > True.  But simplify-rtx.cc simplifies
> > 
> > (ltu (reg 17) (const_int 0))
> > 
> > to false when reg 17 is set.
> 
> Is set?  What does that even mean?  Is set to what?

(reg 17) was set to 1.

> > Use the actual comparison isn't issue.  The issue is how
> > 
> > (ltu (reg 17) (const_int 0))
> > 
> > should be simplified when reg 17 is known to be set.
> 
> You need to look at the setter.  It cannot be simplified otherwise.

The backend knows how to evaluate

(ltu:SI (const_int 1 [0x1]) (const_int 0 [0]))

from

(ltu:SI (reg:CCC 17 flags) (const_int 0 [0]))

where (reg:CCC 17 flags) was set to a constant by backend.

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

[segher at gcc dot gnu.org]

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

--- Comment #38 from Segher Boessenkool <segher at gcc dot gnu.org> ---
You cannot put a const_int in a MODE_CC.  It is meaningless.

[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]

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

--- Comment #39 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Segher Boessenkool from comment #38)
> You cannot put a const_int in a MODE_CC.  It is meaningless.

Reg 17 in

(insn 49 10 50 2 (parallel [
            (set (reg:CCC 17 flags)
                (ne:CCC (reg:SI 82 [ a.1_2 ])
                    (const_int 0 [0])))
            (set (reg:SI 92)
                (neg:SI (reg:SI 82 [ a.1_2 ])))
        ]) "107172.c":4:10 680 {*negsi_ccc_1}

becomes const_int 1 since a.1_2 is known non-zero.  Roger's patch simplifies
const_int in a MODE_CC properly.

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

[segher at gcc dot gnu.org]

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

--- Comment #40 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Let me repeat: A const_int cannot be assigned to a MODE_CC.  It has no meaning.
This is invalid RTL.  If it ever works, or worked, that is an accident.

A MODE_CC stands for a comparison (in the mathematical sense).  Saying it is
"1"
would mean what?

[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]

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

--- Comment #41 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Segher Boessenkool from comment #40)
> Let me repeat: A const_int cannot be assigned to a MODE_CC.  It has no
> meaning.
> This is invalid RTL.  If it ever works, or worked, that is an accident.

Can we make it to work with a target hook? It will allow more backed
optimizations.

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

[segher at gcc dot gnu.org]

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

--- Comment #42 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #41)
> (In reply to Segher Boessenkool from comment #40)
> > Let me repeat: A const_int cannot be assigned to a MODE_CC.  It has no
> > meaning.
> > This is invalid RTL.  If it ever works, or worked, that is an accident.
> 
> Can we make it to work with a target hook? It will allow more backed
> optimizations.

No, you cannot.  A lot of generic code will not work with your special
re-interpretation of basic RTL rules.  Just write correct code in your
backend, it is not hard.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |shaohua.li at inf dot ethz.ch

--- Comment #43 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 107257 has been marked as a duplicate of this bug. ***

[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]

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

--- Comment #44 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Segher Boessenkool from comment #42)
> (In reply to H.J. Lu from comment #41)
> > (In reply to Segher Boessenkool from comment #40)
> > > Let me repeat: A const_int cannot be assigned to a MODE_CC.  It has no
> > > meaning.
> > > This is invalid RTL.  If it ever works, or worked, that is an accident.
> > 
> > Can we make it to work with a target hook? It will allow more backed
> > optimizations.
> 
> No, you cannot.  A lot of generic code will not work with your special
> re-interpretation of basic RTL rules.  Just write correct code in your
> backend, it is not hard.

Does it look correct:

(set (reg:CCC FLAGS_REG)
     (unspec:CCC [(match_dup 1) (const_int 0)] UNSPEC_CC_NE))

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

[segher at gcc dot gnu.org]

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

--- Comment #45 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Yes, that is fine afaics.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #46 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by H.J. Lu <hjl@gcc.gnu.org>:

https://gcc.gnu.org/g:0e36a9c6915c713d30016cbade97a4b31dcc1350

commit r13-3530-g0e36a9c6915c713d30016cbade97a4b31dcc1350
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Thu Oct 20 11:55:19 2022 -0700

    x86: Replace ne:CCC/ne:CCO with UNSPEC_CC_NE in neg patterns

    In i386.md, neg patterns which set MODE_CC register like

    (set (reg:CCC FLAGS_REG)
         (ne:CCC (match_operand:SWI48 1 "general_reg_operand") (const_int 0)))

    can lead to errors when operand 1 is a constant value.  If FLAGS_REG in

    (set (reg:CCC FLAGS_REG)
         (ne:CCC (const_int 2) (const_int 0)))

    is set to 1, RTX simplifiers may simplify

    (set (reg:SI 93)
         (neg:SI (ltu:SI (reg:CCC 17 flags) (const_int 0 [0]))))

    as

    (set (reg:SI 93)
         (neg:SI (ltu:SI (const_int 1) (const_int 0 [0]))))

    which leads to incorrect results since LTU on MODE_CC register isn't the
    same as "unsigned less than" in x86 backend.  To prevent RTL optimizers
    from setting MODE_CC register to a constant, use UNSPEC_CC_NE to replace
    ne:CCC/ne:CCO when setting FLAGS_REG in neg patterns.

    gcc/

            PR target/107172
            * config/i386/i386.md (UNSPEC_CC_NE): New.
            Replace ne:CCC/ne:CCO with UNSPEC_CC_NE in neg patterns.

    gcc/testsuite/

            PR target/107172
            * gcc.target/i386/pr107172.c: New test.

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

[roger at nextmovesoftware dot com]

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

--- Comment #47 from Roger Sayle <roger at nextmovesoftware dot com> ---
I really don't believe that using UNSPEC here is the correct way to go, but it
appears to be the (only?) approach that Segher is prepared to approve.  Hohum.

[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]

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

--- Comment #48 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Roger Sayle from comment #47)
> I really don't believe that using UNSPEC here is the correct way to go, but
> it appears to be the (only?) approach that Segher is prepared to approve. 
> Hohum.

I wish we could avoid UNSPEC.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #49 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So is the wrong-code issue now fixed?
If yes, we should either close or at least drop the [13 Regression] part for it
if you want to keep it as a reminder that it would be nice to get rid of the
UNSPEC.

[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]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #50 from H.J. Lu <hjl.tools at gmail dot com> ---
Fixed.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #51 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:69185294f322dd53d4e1592115014c5488302e2e

commit r14-1405-g69185294f322dd53d4e1592115014c5488302e2e
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Tue May 30 14:40:50 2023 +0100

    PR target/107172: Avoid "unusual" MODE_CC comparisons in simplify-rtx.cc

    I believe that a better (or supplementary) fix to PR target/107172 is to
    avoid producing incorrect (but valid) RTL in
    simplify_const_relational_operation when presented with questionable
    (obviously invalid) expressions, such as those produced during combine.
    Just as with the "first do no harm" clause with the Hippocratic Oath,
    simplify-rtx (probably) shouldn't unintentionally transform invalid RTL
    expressions, into incorrect (non-equivalent) but valid RTL that may be
    inappropriately recognized by recog.

    In this specific case, many GCC backends represent their flags register via
    MODE_CC, whose representation is intentionally "opaque" to the middle-end.
    The only use of MODE_CC comprehensible to the middle-end's RTL optimizers
    is relational comparisons between the result of a COMPARE rtx (op0) and
zero
    (op1).  Any other uses of MODE_CC should be left alone, and some might
argue
    indicate representational issues in the backend.

    In practice, CPUs occasionally have numerous instructions that affect the
    flags register(s) other than comparisons [AVR's setc, powerpc's mtcrf,
    x86's clc, stc and cmc and x86_64's ptest that sets C and Z flags in
    non-obvious ways, c.f. PR target/109973].  Currently care has to be taken,
    wrapping these in UNSPEC, to avoid combine inappropriately merging flags
    setters with flags consumers (such as conditional jumps).  It's safer to
    teach simplify_const_relational_operation not to modify expressions that
    it doesn't understand/recognize.

    2023-05-30  Roger Sayle  <roger@nextmovesoftware.com>

    gcc/ChangeLog
            PR target/107172
            * simplify-rtx.cc (simplify_const_relational_operation): Return
            early if we have a MODE_CC comparison that isn't a COMPARE against
            const0_rtx.

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

[shaohua.li at inf dot ethz.ch]

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

--- Comment #52 from Shaohua Li <shaohua.li at inf dot ethz.ch> ---
*** Bug 107257 has been marked as a duplicate of this bug. ***