On 12/19/2009 01:07 AM, Joern Rennecke wrote:
Quoting Michael Eager <ea...@eagercon.com>:
Hi --
I'm working on creating the cstore and cbranch templates
for the Xilinx MicroBlaze processor.
In theory cstore / cbranch should be the future, but the last time I tried
to use them, they didn't quite work right yet, particularily if you have
an incomplete comparison set. Because of delays with the Copyright
assignment, fixing the middle-end was not an efficient option, so I went
for the old hack with separate compare and condjump / cstore patterns.
Well, 4.5 has only cbranch/cstore. :-)
> (set (reg:CC rD) (eq:CC (reg:SI rA) (reg:SI rB))
>
> followed by a branch:
>
> (if_then_else
> (eq:CC (reg:CC rD) (const_int 0))
> (label_ref xx)
> (pc)))
If there is only one instruction for comparison, the first insn should
be (set (reg:CC rD) (compare:CC (reg:SI rA) (reg:SI rB))). If there are
many, having eq:CC in the first insn is fine but then the second should
be (ne:CC (reg:CC rD) (const_int 0))
Now you have (eq:CC (eq:CC (reg:SI rA) (reg:SI rB)) (const_int 0)),
which is exactly the opposite of what you mean, because (eq <condition>
0) means "check if the condition is false" and hence "reverse the
condition". So CSE sees a reversed condition, thinks the loop must
execute while the variable _is_ zero, and propagates zero inside the loop.
Note that the cmpMM+bXX+sXX -> cbranchMM4/cstoreMM4 conversion usually
can be done in a completely mechanical fashion. It is usually a matter
of defining the right predicates for the operator operand of
cbranch/cstore (operand zero and one, respectively), especially if (as
most ports did) the MicroBlaze port's cmpMM patterns only saved their
operands.
Paolo
