On Mon, Apr 10, 2006 at 03:23:43PM +0200, Frank Riese wrote:
>
> Most of the instructions of the target machine only support registers as
> operands. E.g., a store to a memory location (STO) must always take a
> register containing the address of the memory location and another register
> with the data to be written to that location as arguments. The assembler does
> not support any arithmetic expressions. The only way to get a constant
> directly into a register is to load the high and low part of it with two
> instructions (LDH/LDL).
Can it at least add (small) immediates to registers?
> From what I understood when reading the GCC internals
> docs "GO_IF_LEGITIMATE_ADDRESS" might be the right place to tackle this
> problem. I took that macro from the PDP-11 backend and tried to adjust it to
> my needs.
IIRC, the PDP-11 is famous for accepting complex addresses, i.e. quite the
opposite of your target machine, which is so simple I would suggest you write
it from scratch. Does it need to be more than
#define GO_IF_LEGITIMATE_ADDRESS(XMODE, X, LABEL) \
if (REG_P (X)) \
goto LABEL;
?
A subtle detail of GCC is that (call ) expressions have an extra (mem )
around the function address. I.e. (call (mem:HI (symbol_ref "foobar")))
or (call (mem:HI (reg:HI 4))) instead of just (call (symbol_ref "foobar"))
or (call (reg:HI 4)). However, even if GO_IF_LEGITIMATE_ADDRESS() rejects
(mem:HI (symbol_ref "foobar")) then it can show up in a (call ) expression.
> ../../gcc-4.0.2/gcc/libgcc2.c: In function '__muldi3':
> ../../gcc-4.0.2/gcc/libgcc2.c:533: error: unable to find a register to spill
> in class 'GENERAL_REGS'
> ../../gcc-4.0.2/gcc/libgcc2.c:533: error: this is the insn:
>
> (insn 260 259 266 4 ../../gcc-4.0.2/gcc/libgcc2.c:533 (set (reg/f:HI 5 R[5]
> [+6 ])
> (subreg:HI (reg:SI 102) 2)) 14 {movhi} (nil)
> (expr_list:REG_DEAD (reg:SI 102)
> (nil)))
Try to add -fdump-rtl-greg or -fdump-rtl-greg-details when compiling
__muldi3(). This will generate a libgcc2.c.*.greg file which will say
exactly which reloads insn 260 has and which one is failing.
1) Does BP really have to be fixed? You are sufficiently desparate for
registers than you'll not fix BP unless the hardware itself mandates this.
2) GCC generally doesn't handle multi-word registers well. Even if you ask
for a subreg, it will either load it all into registers or nothing at all.
Richard Henderson posted a "multi-word subreg lowering" patch a while ago,
which might help. See
<URL:http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00554.html>. The patch
needs to be updated to work on current mainline, though.
3) Reload sometimes fritters away registers. DJ Delorie recently submitted a
patch to allow chaining of reloads, which reduces the number of registers
needed in some cases. This will only help you if you upgrade your code base
to mainline, though.
If you can, develop against mainline rather than an old version of GCC.
> So, I am wondering: how does that error affect the generated compiler and
> what
> is the reason for it?
It means that the compiler is unable to generate code is some cases. It
doesn't mean that the code it does generate is wrong.
> I read in other posts that reloading is supposed to be one of the trickiest
> parts to get right with an initial port.
If you have few (meaning less than about 8) free registers, they are
small (say, 16 bits or less each), maybe not even the same size and/or some
instructions require the operands to be in specific registers, then yes,
definitely.
> I still have a hard time understanding how reloading works.
I've been single stepping through various parts of reload over the last five
months and still don't understand many parts of it, but I'll help you with
those parts that I do understand.
> The information I found in the gcc
> internals docs and other parts of the inet are pretty widespread. I would be
> glad if someone knows a page that specifically discusses reloading.
>
> I tried to post everything of relevance to the problem. If you need anything
> else, please ask and I will post it.
--
Rask Ingemann Lambertsen
