gcc-3.3 problem with reloading byte into address register on ColdFire

Peter Barada peter@baradas.org
Thu Jul 10 15:33:00 GMT 2003


>>>Why don't you save all the effort with secondary reloads etc
>>>and just prohibit QImode values in ADDR_REGS entirely with
>>>HARD_REGNO_MODE_OK?  Yes, it prohibits you using ADDR_REGS
>>>for temporaries, but it is not clear to me that that gets
>>>you better code.
>
>>I'll try the following out and see what happens:
>>
>>/* Value is 1 if hard register REGNO can hold a value of machine-mode MODE.
>>   On the 68000, the cpu registers can hold any mode but the 68881 registers
>>   can hold only SFmode or DFmode.  Prevent QImode from being placed
>>   into an address register. */
>>
>>#define HARD_REGNO_MODE_OK(REGNO, MODE) \
>>  ((((REGNO) >= 8 && (REGNO) < 16) && ((MODE) == QImode)) ? 0 :    \
>>  (((REGNO) < 16                                                   \
>>    && !((REGNO) < 8 && (REGNO) + GET_MODE_SIZE (MODE) / 4 > 8))   \
>>   || ((REGNO) >= 16 && (REGNO) < 24                               \
>>       && (GET_MODE_CLASS (MODE) == MODE_FLOAT                     \
>>	   || GET_MODE_CLASS (MODE) == MODE_COMPLEX_FLOAT)         \
>>       && GET_MODE_UNIT_SIZE (MODE) <= 12)))
>
>That failed with:
>
>[peter@baradas ice]$ /tmp/m68k-elf-3.3/bin/m68k-elf-gcc -O1 -S -m5307 -S ice.c
>ice.c: In function `_dtostr':
>ice.c:72: error: unable to find a register to spill in class `ADDR_REGS'
>ice.c:72: error: this is the insn:
>(insn 127 126 130 5 0x4001f2c0 (set (subreg:SI (reg/v:QI 41) 0)
>        (plus:SI (subreg:SI (reg/v:QI 41) 0)
>            (const_int 32 [0x20]))) 100 {*addsi3_5200} (nil)
>    (nil))
>ice.c:72: confused by earlier errors, bailing out
>
>Should I try removing the 'a' constraints from the movqi pattern?

Nope, removing the 'a' constraint still failed. So somewhere gcc
thinkgs it can use an address register to hole a QImode even though
HARD_REGNO_MODE explicitely prevents this.  I had removed all the
other suggested changes(which didn't work) and just tried the above
two.

Any other suggestions?

-- 
Peter Barada
peter@baradas.org



More information about the Gcc mailing list