田晓南 wrote:
> Hello, guys:
> The porting is really a difficult and huge job. So many things I
> don't know or miss result in countless bugs.
>
Definitely true. Though it gets easier the 2nd, 3rd, 4th, time around :-)
>
> Here I encounter some unrecognizable RTL (R0 to R15 are registers. I
> hate the unrecognizable RTL insns always coming about, and I wanna end it.):
> (insn 264 191 193 15 (set (reg:HI 5 R5)
> (subreg:HI (mem:SI (plus:SI (reg/f:SI 14 R14)
> (const_int 12 [0xc])) [0 crc+0 S4 A32]) 0)) -1 (nil)
> (nil))
>
> (insn 261 197 200 14 (set (reg:HI 5 R5)
> (subreg:HI (mem:SI (reg/f:SI 14 R14) [7 crc.16+0 S4 A32]) 0)) -1
> (nil)
> (nil))
>
OK. Subregs of MEMs are a little special. In general, you don't want to
see these at all. I wouldn't necessarily expect this to be a
PROMOTE_MODE problem.
As others have suggested, find the first pass where you see a (subreg
(mem)) expression. That will be a big help. Extra credit if you can
correlate the insns in that dump with insns in the previous dump file
which would show how the pass in question modified the RTL incorrectly.
Given that it should be relatively easy to start digging into the problem.
>
> (insn:HI 17 13 14 0 (set (mem/s:SI (plus:SI (mem/f:SI (reg/f:SI 14 R14) [15
> header+0 S4 A32])
>
> (const_int 32 [0x20])) [10 <variable>.private_bits+0 S4
> A32])
>
> (reg:SI 4 R4 [56])) 8 {store_si} (insn_list:REG_DEP_TRUE 13
> (insn_list:REG_DEP_TRUE 6 (nil)))
>
> (expr_list:REG_EQUAL (const_int 0 [0x0])
>
> (nil)))
>
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.
Jeff
