approaches to carry-flag modelling in RTL

[Peter Bigot <bigotp@acm.org>]

I'm rewriting a back-end originally based on AVR to eliminate insns for
multi-word operations (output templates like "add\;addc") and to use MODE_CC
instead of an unusual attribute-based approach.  The motivation is that I've
mostly found gcc does a better job than the existing back-end if it's shown
what's actually going on.

Part of this update requires correctly modelling the carry flag, for
plus/minus and for rotate through carry.  As noted in recent email here,
preserving the correct instruction order when expanding multi-word expressions
requires a set/use relation between the word-mode insns rather than a
simple clobber/use relation.

I've found several examples where back-ends model the carry in RTL.

Sparc does:

        (plus:SI
          (plus:SI
            (match_operand:SI 1 "arith_operand" "%r")
            (match_operand:SI 2 "arith_operand" "rI"))
          (ltu:SI (reg:CC_NOOV 100) (const_int 0))))]

RX does:

        (plus:SI
          (plus:SI
            (ltu:SI (reg:CC CC_REG) (const_int 0))
            (match_operand:SI 1 "register_operand"  "%0,0,0,0,0,0"))
          (match_operand:SI   2 "rx_source_operand"
"r,Sint08,Sint16,Sint24,i,Q")))

stormy16 does:

        (plus:HI
          (plus:HI
            (match_operand:HI 1 "register_operand" "%0,0,0")
            (zero_extend:HI (reg:BI CARRY_REG)))
          (match_operand:HI 2 "xs_hi_nonmemory_operand" "L,Ir,i")))

The variation points are:

(a) where the carry operand appears in the plus expressions;

(b) whether it's expressed as an ltu zero comparison or a zero_extend.

I'm inclined to follow sparc's lead, but is one or another of the choices
more likely to help combine/reload/etc do a better job?

Thanks.

Peter