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.

My apologies. This was badly expressed and confusing, and I leapt to the 
wrong conclusion.

I believe that the root cause of my problems was that pattern matching
was causing the code to behave in a way that I didn't understand. I
think that I was seeing related two problems.

Firstly, if I defined an instruction which matched a conditional move,
this would allow the function noce_emit_cmove to build the cmove
instruction directly, without resorting to the movhicc pattern. The
presence or absence of movhicc seemed to made no difference.

Secondly, if I changed the conditional move pattern that was being
matched to reject comparisons other than EQ/NE, the code would then
fail at emit_cmp_and_jump_insn_1 instead (by aborting). This failure
occurs before emit_conditional_move is called, so whatever I did in
movhicc to try to fix the problem made no difference.

I have now changed the patterns so that no direct match is available
for noce_emit_cmove to match, and this results in movhicc being
called. I will now look at implementing the original suggestion.

thanks

dan.

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