* Re: PR #5753
@ 2002-03-05 10:31 Peter Barada
0 siblings, 0 replies; 3+ messages in thread
From: Peter Barada @ 2002-03-05 10:31 UTC (permalink / raw)
To: gcc
>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)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: PR #5753
@ 2002-03-05 12:45 Peter Barada
0 siblings, 0 replies; 3+ messages in thread
From: Peter Barada @ 2002-03-05 12:45 UTC (permalink / raw)
To: gcc
>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.
Since QImode can not be placed in address registers, I've tried
modifying HARD_REGNO_MODE_OK() to be:
#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)))
and this caused the compilation to break with:
/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
So to go the next step, I modified LIMIT_RELOAD_CLASS() to evaluate to
DATA_REGS if CLASS is ADDR_REGS and mode is QImode, and this caused
the compilation ot break with:
/tmp/cfprintf4.c:58: Insn does not satisfy its constraints:
(insn 185 258 256 (set (reg:SI 8 %a0)
(plus:SI (reg:SI 0 %d0)
(const_int -100 [0xffffff9c]))) 100 {*addsi3_5200} (nil)
(nil))
So I can see how the reload code replaced the previous subreg with
%d0, and why it doesn't match... I guess the real question I have to
figure out is why is class ADDR_REGS in the first place...
1) Are my changes to these three macros the right changes?
2) Am I on the right track?
--
Peter Barada Peter.Barada@motorola.com
Wizard 781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: PR #5753
@ 2002-03-04 15:22 Peter Barada
0 siblings, 0 replies; 3+ messages in thread
From: Peter Barada @ 2002-03-04 15:22 UTC (permalink / raw)
To: gcc
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.
The compiler reports:
m68k-elf-gcc -fno-exceptions -S -gstabs -malign-int -Wall -Wno-format -m5200 /tmp/cfprintf4.c -o /tmp/cfprintf4.s -da
/tmp/cfprintf4.c: In function `_vformat':
/tmp/cfprintf4.c:58: Insn does not satisfy its constraints:
(insn 258 38 185 (set (reg:QI 8 %a0)
(mem/f:QI (plus:SI (reg/f:SI 14 %a6)
(const_int -1 [0xffffffff])) 0)) 37 {*m68k.md:1060} (nil)
(nil))
/tmp/cfprintf4.c:58: Internal compiler error in final_scan_insn, at final.c:2876
Which indicates that it is trying to load a QImode from memory and
into an address register which the 68k architecture allows, but the
ColdFire architecture rejects.
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
1) Is limiting HARD_REGNO_MODE_OK() correct in this case?
While debugging this, I find its failing because find_reg is returning
a zero. At the start of the second loop in find_reg (the one that tests each
of the bits in not_usable), the values of the various bitstrings is:
Breakpoint 8, find_reg (chain=0x82dd164, order=1)
at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-304/gcc/reload1.c:1701
(gdb) p/x bad_spill_regs
$20 = 0xffc000
(gdb) p/x bad_spill_regs_global
$21 = 0x4000
(gdb) p/x reg_class_contents[rl->class]
$22 = 0xff00
(gdb) p rl->class
$23 = ADDR_REGS
(gdb) p/x not_usable
$24 = 0xffffc0ff
(gdb) p rl->mode
$25 = QImode
(gdb) p/x used_by_other_reload
$26 = 0x0
And it fails since the only registers available int not_usable are the
address registers a0 through a5(zero bits 8..13). Apparently all the
data registers are taken due to the inverse of reg_class_contents.
Now the next question is why is the class ADDR_REGS while the mode is
QImode?
2) How can rl->mode be QImode while the class is ADDR_REGS.
3) Any ideas where I should look from here?
--
Peter Barada Peter.Barada@motorola.com
Wizard 781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax)
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-03-05 20:45 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-05 10:31 PR #5753 Peter Barada
-- strict thread matches above, loose matches on Subject: below --
2002-03-05 12:45 Peter Barada
2002-03-04 15:22 Peter Barada
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).