On Sat, 29 Oct 2011, Peter Bigot wrote:
> On Fri, Oct 28, 2011 at 11:59 AM, Richard Henderson <r...@redhat.com> wrote:
> Based on what I've encountered so far, between having to duplicate many
> insns (one with CC_REG, one without), adding splits to convert between them,
> and making a hash of the templates for the peepholes that enable efficient
> access to volatile RMW peripheral memory, it looks like using CC_MODE is
> going to create a maintenance nightmare.

I came to the somewhat the same conclusion for CRIS where all
insns set condition codes except move to memory and a "add
reg1,reg2" (no immediate operand) and to/from special registers:
there'll one clobbering and one CC_REG-setting pattern plus a
load of others (peephole2's mostly) to get an exact match.

What would help is a kind of iterator that (also) affects the
form of the insn, so you could match the clobbering and the
cc0-setting insn in the same (iterator-using) pattern.  BTW, I
don't think it helps that someone decided the canonical form of
a parallel that includes a CC-setter must have the CC-setting
*first* (contrasting with the position of clobbers)...

To answer your later question: The main win from moving *from*
cc0 is easier maintenance for the *rest* of gcc: no need to
special-case cc0; its implicit setting is a complicating factor
when working at the RTL level.  Albeit some minor optimizations
are disabled when cc0 is encountered (IIRC), last I checked a
trivial transformation from cc0 to explicit CC_REG loses
performance; additional work (peephole2's and the equivalence of
avr_reorg) is needed to get it back.

brgds, H-P

Reply via email to