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

Peter Barada peter@the-baradas.com
Mon Apr 26 21:06:00 GMT 2004


>> 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?

ColdFire allows for d8(Ax,Xi*SF) where Xi is either an address or data
register, abd the scalefactor(SF) is either 1,2,4, or 8 if the FPU is
attached, so INDEX_REG_CLASS looks right, at least for ColdFire.

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

The constraint is limited to:

(define_insn ""
  [(set (match_operand:QI 0 "nonimmediate_operand" "=d<Q>,dm,d")
	(match_operand:QI 1 "general_src_operand" "dmi,d<Q>,di"))]
  "TARGET_COLDFIRE"
  "* return output_move_qimode (operands);")

Which doesn't allow for IKLs.  This constraint *should* work, right?
Which ColdFire pattern are you seeing 'mrIKLs' on that you think should be
changed?

-- 
Peter Barada
peter@the-baradas.com



More information about the Gcc mailing list