This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PR #5753
- From: Peter Barada <pbarada at mail dot wm dot sps dot mot dot com>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 5 Mar 2002 13:30:20 -0500
- Subject: Re: PR #5753
>I've reported a PR (see #5753) while compiling some code from a
>m68k-elf configured 3.0.4 compiler for -m5200. I'm attempting to
>figure out a fix.
>I've tried to modify HARD_REGNO_MODE_OK to be:
>
>/* 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. On ColdFire, no instruction exists
> to move bytes into or out of the address registers. */
>
>#define HARD_REGNO_MODE_OK(REGNO, MODE) \
> ((TARGET_5200 && ((REGNO) >= 8 && (REGNO) < 16) \
> && GET_MODE_SIZE (MODE) == 1) ? 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)))
>
>This rejects placing bytes into address registers, and I can successfully
>build a compiler, but when I try this code again I get:
>
>/tmp/crap-304-new/bin/m68k-elf-gcc -c -gstabs -malign-int -m5200 /tmp/cfprintf4.c -o /tmp/cfprintf4.o
>/tmp/cfprintf4.c: In function `_vformat':
>/tmp/cfprintf4.c:58: Unable to find a register to spill in class `ADDR_REGS'.
>/tmp/cfprintf4.c:58: This is the insn:
>(insn 185 184 186 (set (reg:SI 68)
> (plus:SI (subreg:SI (mem/f:QI (plus:SI (reg/f:SI 14 %a6)
> (const_int -1 [0xffffffff])) 0) 0)
> (const_int -100 [0xffffff9c]))) 100 {*addsi3_5200} (nil)
> (nil))
>/tmp/cfprintf4.c:58: confused by earlier errors, bailing out
I've been debugging further trying to figure out why when find_reg
fails, the class is ADDR_REGS and the mode is QImode, a combination
that's illegal on the ColdFire.
At line 916 of reload.c is a telling comment:
/* If we are reloading a (SUBREG constant ...), really reload just the
inside expression in its own mode. Similarly for (SUBREG (PLUS ...)).
If we have (SUBREG:M1 (MEM:M2 ...) ...) (or an inner REG that is still
a pseudo and hence will become a MEM) with M1 wider than M2 and the
register is a pseudo, also reload the inside expression.
At this point, the class/mode is legal (ADDR_REGS/SImode):
(gdb) fra 0
#0 push_reload (in=0x401b68c0, out=0x0, inloc=0x401b68e4, outloc=0x0,
class=ADDR_REGS, inmode=SImode, outmode=VOIDmode, strict_low=0,
optional=0, opnum=1, type=RELOAD_FOR_INPUT)
at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-304/gcc/reload.c:946
(gdb) up
#1 0x081cb7b5 in find_reloads (insn=0x401b7340, replace=0, ind_levels=0,
live_known=0, reload_reg_p=0x82a1f80)
at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-304/gcc/reload.c:3648
(gdb) call debug_rtx(insn)
(insn 185 184 186 (set (reg:SI 68)
(plus:SI (subreg:SI (mem/f:QI (plus:SI (reg/f:SI 14 %a6)
(const_int -1 [0xffffffff])) 0) 0)
(const_int -100 [0xffffff9c]))) 100 {*addsi3_5200} (nil)
(nil))
Then at line reload.c:1020, inmode changes from SImode to QImode since
it wants the mode of the memory reference. At this point I'm
wondering if the class needs to change since QImodes can't go into
ADDR_REGS. The class choice comes from the addsi3_5200 instruction:
(define_insn "*addsi3_5200"
[(set (match_operand:SI 0 "nonimmediate_operand" "=m,?a,?a,r")
(plus:SI (match_operand:SI 1 "general_operand" "%0,a,rJK,0")
(match_operand:SI 2 "general_src_operand" "d,rJK,a,mrIKLs")))]
"TARGET_COLDFIRE"
"* return output_addsi3 (operands);")
Which does allow address registers as an alternative, but only for SImode.
Would changing 'class' to one that can hold 'mode' be legal in this
case, or is there something else that I'm completely overlooking?
Any ideas where I should go from here?
--
Peter Barada Peter.Barada@motorola.com
Wizard 781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax)