This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc-3.4.0 fails for ColdFire(does not satisfy constraints)
Peter Barada <peter@the-baradas.com> writes:
> >> For ColdFire(at least on the newer cores), the immediate add is
> >> faster(but larger) than the moveq/add.
> >
> >OK, then we don't want to use this for Coldfire. But I suspect that
> >we do want to use it for 680x0.
>
> For m68k, the pattern is
>
> (define_insn "*addsi3_internal"
> [(set (match_operand:SI 0 "nonimmediate_operand" "=m,?a,?a,d,a")
> (plus:SI (match_operand:SI 1 "general_operand" "%0,a,rJK,0,0")
> (match_operand:SI 2 "general_src_operand" "dIKLT,rJK,a,mSrIKLT,mSrIKLs")))]
>
>
> "! TARGET_COLDFIRE"
> "* return output_addsi3 (operands);")
>
> Which should work correctly since it would force a register to be used
> to hold the constant, and I'm assuming that by seperating the last two
> alternatives that the compiler will favor a data register over an
> address register.
It will indeed force a register to be used, but I think that in the
general case we do not want to force a register to be used. If we
always force a register to be used, then we increase register
pressure. If we force a register to be spilled due to constraint
failure, then we have generated worse code. The advantage of the
peephole2 approach is that it will use a register only if there is one
available. If all the registers are being used for something else,
then we won't force one of them to be spilled just to hold our
constant.
Either choice will generate worse code in some situations. My guess
is that the peephole2 approach will be better on average. But it
should be tested on some benchmarks.
Ian