Compiler porting: Problem with stack slots

[Vasanth <lonewolf_av at yahoo dot com>]

Hi all,

We are porting GCC 3.4.1 to a MIPS like RISC
processor. We already had GCC 2.95.4 ported, about 2
years ago. Now, we are trying to catch up and forward
port.

I am really stuck with a problem and would appreciate
any pointers that I can get. 

I am encountering the following problem with "movsi"
patterns.

(insn 593 592 597 43
/home/vasanth/work/gcc/gcc-3.4.1/gcc/unwind-dw2-fde.c:467
(set (mem/s:SI (plus:SI (mem:SI (plus:SI (reg/f:SI 1
r1)
                        (const_int 60 [0x3c])) [28 S4
A32])
                (const_int 4 [0x4])) [18
<variable>.count+0 S4 A32])
        (reg/v:SI 9 r9 [orig:144 k ] [144])) 43
{movsi_internal2} (insn_list:REG_DEP_OUTPUT 591 (nil))


I have the following questions. 

1) The mem:SI (plus:SI (mem:SI (plus:SI (reg:SI r1)
(const_int))) (const_int)) pops up during .greg phase.
What seems to be happening is, due to register
pressure, a previously (reg:SI <pseudo>) gets assigned
to a stack slot (r1 + 60). So, the first question is,
isn't the reload phase of GCC responsible for making
sure that stack slots, will have appropriate insns
generated to move the stack slot into a register,
prior to the above instruction? 

2) Alternatively, am I supposed to redefine my
"memory" operand constraint to allow such double
indirection operands. This I presume should be done in
GO_IF_LEGITIMATE_ADDRESS. As far as I can see, no
other  equivalent architecture, does allow this kind
of complex memory operand.

3) Am I to handle this kind of complexity which pops
up in an insn, with define_splits? If so, then how can
I achieve the effect of the above insn, with multiple
insns and WITHOUT creating new pseudos. Since this
happens after the reload phase.


Thanks in advance for any help,
Vasanth


=====
"I drink, to make other people interesting !"


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail