[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
Wed Oct 12 17:50:22 GMT 2022
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.
More information about the Gcc-bugs
mailing list