https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3507
--- Comment #71 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Drea Pinski from comment #70)
> (In reply to Uroš Bizjak from comment #68)
> > For the testcase in the Comment #0, we can use this PoC i386 patch:
>
> Right for x86 where sub always sets the CC, this will definitely be useful.
> I wonder if most of the define_expand for x86 should instead of just
> `clobber CC`, express what the CC is set to. I think that is kind of how
> the old CC0 worked even. I think this is true of the 68k backend and the
> AVR backend should be done a similar fashion (I think the AVR backend was
> CC0 at one point).
Not really, because other arithmetic insns set (limited) bits of flags reg
based on the result of the operation:
(insn 8 7 9 2 (parallel [
(set (reg:CCGOC 17 flags)
(compare:CCGOC (plus:SI (reg:SI 101 [ a ])
(reg:SI 102 [ b ]))
(const_int 0 [0])))
(set (reg/v:SI 98 [ c ])
(plus:SI (reg:SI 101 [ a ])
(reg:SI 102 [ b ])))
]) "add-f.c":8:6 315 {*addsi_2}
(expr_list:REG_DEAD (reg:SI 101 [ a ])
(expr_list:REG_DEAD (reg:SI 102 [ b ])
(nil))))
while MINUS insn *is the equivalent* of the COMPARE:
(insn 7 4 23 2 (parallel [
(set (reg:CC 17 flags)
(compare:CC (reg/v:DI 101 [ a ])
(reg/v:DI 102 [ b ])))
(set (reg/v:DI 100 [ <retval> ])
(minus:DI (reg/v:DI 101 [ a ])
(reg/v:DI 102 [ b ])))
]) "pr3507.c":2:16 452 {*subdi_3}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
In the first case, combine pass can synthesize the combined insn, while in the
second case, it is really a job for the CSE pass. So, if we go this way, it is
only "sub<mode>3" pattern that is of interest.
