daniel.tian wrote: >> 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? > No, you do not want to accept that form since your target doesn't support it. I wanted you to verify that GO_IF_LEGITIMATE_ADDRESS was rejecting that form.
So probably the next step would be to trace find_reloads for your insn and see what reloads are recorded/performed. Jeff
