Re: gcc-3.4.0 fails for ColdFire(does not satisfy constraints)

[Ian Lance Taylor <ian at wasabisystems dot com>]

Peter Barada <peter@the-baradas.com> writes:

> Now fails with:
> 
> printf.c: In function `_fpmaxtostr':
> printf.c:2454: error: unable to find a register to spill in class `ADDR_REGS'
> printf.c:2454: error: this is the insn:
> (insn 537 536 538 38 (set (subreg:SI (reg/v:QI 50 [ mode ]) 0)
>         (plus:SI (subreg:SI (reg/v:QI 50 [ mode ]) 0)
>             (const_int 32 [0x20]))) 90 {*addsi3_5200} (nil)
>     (nil))
> 
> Breakpoint 1, fancy_abort (
>     file=0x82582e0 "/home/peter/work/src/ucLinux/ucTools/gcc-3.4.0/gcc/reload1.c", 
>     line=1874, function=0x82580f7 "spill_failure")
>     at /home/peter/work/src/ucLinux/ucTools/gcc-3.4.0/gcc/diagnostic.c:584
> 
> 
> Any suggestions where I go from here are most appreciated.

I think INDEX_REG_CLASS looks a bit fishy to me.  GENERAL_REGS is fine
for 68020, but is it really right for 68000 or Coldfire?  Perhaps it
should be DATA_REGS?

Actually, I don't understand the abort.  The last alternative for the
insn permits r,0,r, which can be matched by reloading the constant 32
into any register, so why is the code trying to spill ADDR_REGS?  Why
not GENERAL_REGS?

Using mrIKLs in a constraint is tricky stuff, anyhow.  It can often
lead to better code by causing gcc to use moveq to load some other
register, and then do the addition.  But that increases register
pressure; if no other register is available, then the resulting code
is actually worse.  It might be better to not use the 's' constraint,
but to instead use a peephole2 which uses match_scratch, a technique
which was not available when the m68k backend was written.

Ian