This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 "" ""))
   "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".

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]