Re: 答复: How to deal with unrecognizable RTL code

[Jeff Law <law@redhat.com>]

daniel.tian wrote:
>
>
>   
>> This looks like a different problem. What pass generates insn 17? What
>> does insn 17 look like in the prior pass? If r14 is your stack/frame
>> pointer, this might point to a problem in how your port interacts with
>> register allocation/reload as reload can replace a pseudo with an
>> equivalent memory location.
>>
>>     
> Here is RTL in *.22.lreg:
> (insn:HI 12 13 20 0 (set (reg/v/f:SI 91 [ frame ])
>         (reg:SI 5 R5 [ frame ])) 14 {move_regs_si} (nil)
>     (expr_list:REG_DEAD (reg:SI 5 R5 [ frame ])
>         (nil)))
>
> (insn:HI 20 12 11 0 (set (reg:SI 88 [ D.1221 ])
>         (mem/s:SI (plus:SI (reg/v/f:SI 91 [ frame ])
>                 (const_int 4 [0x4])) [13 <variable>.mode+0 S4 A32])) 11
> {load_si} (insn_list:REG_DEP_TRUE 12 (nil))
>     (nil))
> You can see the two insns are right. Reg91 <-- R5,  Reg88 <-- (R91 + 4).
>
> But in *.23.greg, RTL is wrong:
> (insn:HI 12 13 545 0 (set (reg:SI 5 R5)
>         (reg:SI 5 R5 [ frame ])) 14 {move_regs_si} (nil)
>     (nil))
>
> (insn 545 12 20 0 (set (mem/f:SI (plus:SI (reg/f:SI 14 R14)
>                 (const_int 172 [0xac])) [35 frame+0 S4 A32])
>         (reg:SI 5 R5)) 8 {store_si} (nil)
>     (nil))
>
> (insn:HI 20 545 11 0 (set (reg:SI 6 R6 [orig:88 D.1221 ] [88])
>         (mem/s:SI (plus:SI (mem/f:SI (plus:SI (reg/f:SI 14 R14)
>                         (const_int 172 [0xac])) [35 frame+0 S4 A32])
>                 (const_int 4 [0x4])) [13 <variable>.mode+0 S4 A32])) 11
> {load_si} (insn_list:REG_DEP_TRUE 12 (nil))
>     (nil))
>
> Why there is a crap insn existence: R5 <-- R5?? 
>   
I wouldn't worry too much about that insn, it's a nop move and will be
eliminated. However...

> The following RTL insn is right which means storing R5 register to a
> specific memory location.
>   
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