CC_MODE and cc0

[Zack Weinberg]

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

> 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")

Oh, cool, I wonder when it got added.

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

I would suggest that it be documented first.

zw