This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]