CC_MODE and cc0

[Kazu Hirata]

Hi Zack,

> The biggest problem with all the other ways to represent conditional
> operations is that the RTL "expander" (the code that produces RTL from
> abstract syntax trees) has never been fully weaned away from
> assumptions embedded in the cc0 model.  No matter what your hardware
> does, you've got to use the same named patterns to represent a
> comparison and branch, and they just don't fit some architectures.
> One winds up gluing it all together with define_expand patterns and
> global variables to save state between the compare and the branch.
> Look at the Alpha back end for a good example.

Actually, I found something called "cbranch<mode>4" pattern a few days
ago.  Look for cbranch_optab in genopinit.c and optabs.c.  Basically,
it allows you to write something like

(define_insn "cbranchqi4"
  [(set (pc)
	(if_then_else (match_operator 0 "comparison_operator" ""
			[(match_operand 1 "register_operand" "r")
			 (match_operand 2 "nonmemory_operand" "rni")])
		      (label_ref (match_operand 3 "" ""))
		      (pc)))]
  ""
  "blah")

Of course, it's up to you to use this like so:

(define_expand "cbranchqi4"
  [(set (reg 17)
	(compare (match_operand 1 "register_operand" "")
		 (match_operand 2 "nonmemory_operand" "")))
   (set (pc)
	(if_then_else (match_operator 0 "comparison_operator" ""
			[(reg 17) (const_int 0)])
		      (label_ref (match_operand 3 "" ""))
		      (pc)))]
  ""
  "")

In any case, this is an *undocumented* feature of GCC.  So far only
arm.md has "cbranchsi4".

Shall we start eliminating those global variables holding comparison
operands by switching to "cbranch" pattern?

Kazu Hirata