> Which means that reg 91 was spilled (ie, it did not get a hard register
> assigned). You can verify this by looking at reg_equiv_mem[91] just
> before this loop in reload1.c:
>
> /* This loop scans the entire function each go-round
> and repeats until one repetition spills no additional hard regs. */
> for (;;)
>
> Presumably reload then replaced reg91 with its equivalent memory
> location in insn 20, thus giving you the somewhat strange looking (mem
> (plus (mem (...)). This is normal behaviour so far. Presumably your port
> rejects (plus (mem (...)) in GO_IF_LEGITIMATE_ADDRESS?
>
>
> You'll probably want to put a breakpoint at this point in reload1.c:
> /* Now eliminate all pseudo regs by modifying them into
> their equivalent memory references.
> The REG-rtx's for the pseudos are modified in place,
> so all insns that used to refer to them now refer to memory.
>
> For a reg that has a reg_equiv_address, all those insns
> were changed by reloading so that no insns refer to it any longer;
> but the DECL_RTL of a variable decl may refer to it,
> and if so this causes the debugging info to mention the variable. */
>
> When you hit that breakpoint look at insn 20. If it still references
> reg91, then reload thinks that (plus (mem (...))) is a valid address,
> most likely due to a botched GO_IF_LEGITIMATE_ADDRESS macro.
>
> Jeff
>
Actually, you are right. I have traced the GO_IF_LEGITIMATE_ADDRESS. I do
reject the memory form like (plus (mem (...))). And my Risc do not support
the memory reference like this. You mean I should accept the form in
GO_IF_LEGITIMATE_ADDRESS macro?
Thanks.
Daniel.
_______________________________________________
Best Regards
Daniel Tian
Mavrix Technology, Inc.
Address：200 Zhangheng Road, #3501, Building 3, Zhangjiang Hi-tech Park,
Shanghai, P.R.China (201204)
Tel:86(21)51095958 - 8125
Fax:86(21)50277658
email：daniel.t...@mavrixtech.com.cn
www.mavrixtech.com
