[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    =?gb2312?B?tPC4tDogSG93IHRvIGRlYWwgd2l0aCB1bnJlY29nbml6YWJsZSBSVEwgY28=?= 	=?gb2312?B?ZGU=?=
From:       "daniel.tian" <daniel.tian () mavrixtech ! com ! cn>
Date:       2009-06-29 9:40:50
Message-ID: 20090629093824.716BB3758001 () mail ! mavrixtech ! com ! cn
[Download RAW message or body]

Hi, Jeff:
> 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.
>
Yeah, You are right. Now I, making reference to ARM movm pattern, wanna
rewrite the movm pattern. Now the movm pattern do not performs well.



> 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?? 
The following RTL insn is right which means storing R5 register to a
specific memory location.
The finally insn is weird. Actually, we can see that the location in
(mem/f:SI (plus:SI (reg/f:SI 14 R14) (const_int 172 [0xac])) is R5. I don't
why it is placed and what criteria the displacement bases.

Does Gcc like to merge some RTL? If it does, gcc merge RTL base what?
I mean if the merging happening, some generating RTL will be incorrect.

Thank you for your guys help!
	
Daniel.Tian


_______________________________________________

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.tian@mavrixtech.com.cn

www.mavrixtech.com



[prev in list] [next in list] [prev in thread] [next in thread]