Compiler porting: Problem with stack slots

Sat Oct 9 17:36:00 GMT 2004

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

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

I am encountering the following problem with "movsi"

(insn 593 592 597 43
(set (mem/s:SI (plus:SI (mem:SI (plus:SI (reg/f:SI 1
                        (const_int 60 [0x3c])) [28 S4
                (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,

"I drink, to make other people interesting !"

Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.

More information about the Gcc mailing list