How aggressive is CSE about removing redundant CC sets?

[Ian Lance Taylor]

Kazu Hirata <kazu@cs.umass.edu> writes:

> While converting h8300 port to MODE_CC, I encountered the following
> sequence.
> 
> ;; move r1 to r0, while testing r1
> (parallel [(set (reg:SI 0 r0)
>                 (reg:SI 1 r1))
> 	   (set (reg:CC 12 cc)
>                 (compare:CC (reg:SI 1 r1)
> 			    (const_int 0)))])
> 
> ;; test r1
> (set (reg:CC 12 cc)
>      (compare:CC (reg:SI 1 r1)
> 		 (const_int 0)))
> 
> ;; jump depending on CC
> (set (pc)
>      (if_then_else (eq (reg:CC 12 cc)
> 		       (const_int 0))
> 		   (label_ref 17)
> 		   (pc)))
> 
> Note that the second insn isn't necessary because the first one does
> the same as a side effect of the move insn.  With -O2, the first insn
> didn't go away.  Does anybody know how aggressive CSE is about
> removing redundant CC sets?

As far as CSE is concerned, setting a condition code register is an
expression like any other.  I'm surprised that it doesn't see the
duplication here.  On some platforms the condition code register is
triky because there are multiple MODE_CC modes, but here the
comparisons are evidently in the same mode.

Note that GCSE won't pick up something like this because GCSE doesn't
work on hard registers.  But CSE should see and eliminate equivalent
sets within a single extended basic block.

I do note that your RTL here shows only hard registers.  Remember that
CSE is only run relatively early in the set of passes.  I'm not sure
whether the reload_cse_regs() pass will pick this up--I would expect
it to, but I haven't looked closely at the code recently.

Ian