From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16981 invoked by alias); 5 Mar 2002 18:31:17 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 16838 invoked from network); 5 Mar 2002 18:30:54 -0000 Received: from unknown (HELO motgate.mot.com) (129.188.136.100) by sources.redhat.com with SMTP; 5 Mar 2002 18:30:54 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA22788 for ; Tue, 5 Mar 2002 11:30:53 -0700 (MST)] Received: [from mail.wm.sps.mot.com ([199.10.246.2]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id LAA24162 for ; Tue, 5 Mar 2002 11:30:52 -0700 (MST)] Received: from hyper.wm.sps.mot.com (hyper.wm.sps.mot.com [199.10.246.43]) by mail.wm.sps.mot.com (8.9.3/8.9.3) with ESMTP id NAA18896 for ; Tue, 5 Mar 2002 13:30:16 -0500 Received: by hyper.wm.sps.mot.com (8.11.2) id g25IUK421184; Tue, 5 Mar 2002 13:30:20 -0500 Date: Tue, 05 Mar 2002 10:31:00 -0000 Message-Id: <200203051830.g25IUK421184@hyper.wm.sps.mot.com> From: Peter Barada To: gcc@gcc.gnu.org Subject: Re: PR #5753 X-SW-Source: 2002-03/txt/msg00146.txt.bz2 >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)