Re: If-conversion and conditional move.

[Dan Towner <dant at picochip dot com>]

> Have a look at MIPS. They only support the same two conditional moves, but
> the define_expand does not fail on the rest, but rather generates a compare
> for the other cases and then conditionally moves.

I tried this, but the define_expand is never called for the 
if-conversion. Once the if-conversion has decided to generate a 
conditional move, it doesn't go through the define_expand mechanism to 
generate a sequence of instructions, but only looks for a matching 
define_insn. For the moment, given a conditional move such as `if (C) 
src := dest', I can generate the appropriate instruction for EQ and NE, 
and for unsupported comparisons, generate:

  if (!C) goto bypass
    dest := src
bypass:

This has the desired effect, and works with the if-conversion, but 
misses out the scheduling opportunities available with the real 
conditional move instruction. It generates worse code than the 
non-if-converted original (which is scheduled).

For your info, the DSP I am working with has condition flags, which are 
set using a comparison instruction.

  CMP r0,r1      // Set (implicit) condition flags
  BNE label      // Branch using the (implicit) condition flags

This is different to the MIPS, which  stores the condition in a 
register. It is feasible for the MIPS to generate a register-condition, 
and conditionally move using that register, but this is different to the 
 model I am working with.

dan



> > I have recently been adding conditional move instructions to a GCC port
> > for a 16-bit DSP (i.e., movhicc, etc.). The DSP only supports
> > move-on-equals and move-on-not-equals, not the whole variety of LE, GT,
> > LEU, and so on. The movhicc pattern itself is written to fail if an
> > attempt is  made to generate a conditional move using an unsupported
> > comparison, but the if-conversion code (ifcvt.c) doesn't seem to check
> > that a valid comparison is used. For example, if a simple code block is
> > found with a GT comparison controlling entry, the if-conversion code
> > attempts to generate a conditional move for a GT comparison, which isn't
> > supported. However, rather than giving up, and not performing the
> > conversion, the if-conversion code aborts instead.
> >
> > What is the easiest way to go about solving this problem?
> >   1) change the abort to allow graceful failure, with
> >      fallback to using branches
> >   2) prevent the if-conversion from even being attempted when an
> >      unsupported comparison is used?

=============================================================================
Daniel Towner
picoChip Designs Ltd., Riverside Buildings, 108, Walcot Street, BATH, 
BA1 5BG
dant@picochip.com
07786 702589