ifcvt: cond_exec-like behavior on cc0 machines

[Alexandre Oliva]

On Jul 22, 2003, Alexandre Oliva <aoliva@redhat.com> wrote:

> IIRC, get_condition() may have failed in a case that had one of
> these setting (cc0) before the branch.

Actually, the reason get_condition() failed was that it was not the
function I should be using.  Later on, I realized I wanted
canonicalize_condition, that wouldn't attempt to reverse the
condition, which caused it to sometimes fail, e.g., for (ge (cc0)
(const_int 0)).  Why it failed to reverse it, I didn't investigate (or
I don't remember), since I realized I didn't want it to ever revert
the condition anyway.  With canonicalize_condition(), I got better
results, but init_propagate_block_info() still crashed when it got a
cond_true that looked like (ne (zero_extract reg 1 0) 0), because the
operand of the comparison wasn't a reg or subreg of a reg.

I'm not sure what to do in this case.  Can we just skip the block that
would mark registers as conditionally dead in this case, or do we need
to take some alternate action?

The other thing I'm unsure about is whether ifcvt should require a
canonical condition.  Ports might legitimately define cond_exec using
cc0, but ifcvt wouldn't be able to convert a multi-insn bb to it, but
it could still convert a single-insn bb into a cc0-using cond_exec
insn, and this would simplify ports that actually need a separate
cc0-setting instruction.  OTOH, one can always accept a cc0-less
condition and then split it into a cc0-setting insn followed by the
use, but this could get painful.  In this one port I'm working on, the
conditional insn cannot take a cc0 condition, so I know there are uses
for the canonicalization, but I'm unsure about the alternative.
Comments?

Here's the patch I've got so far, not tested in any reasonable way
(i.e., this is not a patch submission :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cc0-cond-exec.patch
Type: text/x-patch
Size: 1731 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20030723/9ef41657/attachment.bin>
-------------- next part --------------

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer