Re: emit_conditional_move w/o compare insn (was: Full comparisonin 'cbranchsi4' leads to error in gcc 4.0)

[Sami Khawam <S dot Khawam at ee dot ed dot ac dot uk>]

Hi Gary,

Thanks a lot for the tip.

After debugging, the problem seem to be coming from 'emit_conditional_move'
which is called by 'expand_sdiv_pow2' when converting division-by-constants into 
shifting.
The problem is that the architecture I have does not support compare operations: 
It either has a conditional move or a conditional branch instructions (the 
compare operation is part of these instructions).

To make a conditional move, 'emit_conditional_move' generates a seperate compare 
and then a move insns, maybe hoping that these will be later combined into a 
single instruction during the optimization steps.

Would it be possible to tell this to emit_conditional_move so that it generates 
the cmove insn directely?

Many Thanks,

Sami Khawam



Gary Funck wrote:

> > This works fine on gcc 3.4, however on gcc 4.0 it creates an error during 
> > optimization. According to my investigation, the error occurs when there is a 
> > division by a constant power of 2 which needs to be transformed into shifting. 
> > The error generated is:
> >
> > internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:3599
>
>
> The easiest thing to do is to debug gcc: set a breakpoint on fancy_abort, and
> and go up a few levels to emit_cmp_and_jump_insn_1().  Note the incoming
> rtx args (x and y) and mode.  From the looks of the code in there it is looking
> for an instruction pattern that matches, and when no match is found, it tries
> a wider mode, until there are no wider modes, then it aborts.  You need to
> find the mode and rtx arguments that are being passed in, and then understand
> why no matching instruction is found. For example, in your instruction pattern,
>
> (define_insn "cbranchsi4"
>      [(set (pc) (if_then_else
> 		(match_operator 0 "comparison_operator"
> 				[(match_operand:SI 1 "register_operand" "r")
> 				 (match_operand:SI 2 "nonmemory_operand" "r")])	
> 		(label_ref (match_operand 3 "" ""))
> 		(pc)))]
>      ""
>    "c%C0jump %1 %2 %3"
>    [(set_attr "type" "branch")
>     (set_attr "length" "1")]
> )
>
> it isn't prepared to match a memory operand.  Perhaps the optimizer pre-calculated
> a constant, and targeted the constant into memory rather than a register?  In
> that case, there will be no match on the third argument because it is expecting
> a "nonmemoryoperand".