From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15177 invoked by alias); 29 Jun 2009 09:41:10 -0000 Received: (qmail 15152 invoked by uid 22791); 29 Jun 2009 09:41:08 -0000 X-SWARE-Spam-Status: No, hits=4.6 required=5.0 tests=AWL,BAYES_50,CHARSET_FARAWAY_HEADER,MIME_CHARSET_FARAWAY,SARE_HEAD_8BIT_SPAM,SARE_SUB_ENC_GB2312 X-Spam-Check-By: sourceware.org Received: from 178.200.DSNET (HELO mail.mavrixtech.com.cn) (203.110.178.200) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Jun 2009 09:40:58 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.mavrixtech.com.cn (Postfix) with ESMTP id 0E7783758002; Mon, 29 Jun 2009 17:38:25 +0800 (CST) Received: from mail.mavrixtech.com.cn ([127.0.0.1]) by localhost (mail.mavrixtech.com.cn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9s3fpkT11JJ; Mon, 29 Jun 2009 17:38:24 +0800 (CST) Received: from danielshmr (daniel-shmr.actions.com.cn [192.168.95.243]) by mail.mavrixtech.com.cn (Postfix) with ESMTP id 716BB3758001; Mon, 29 Jun 2009 17:38:24 +0800 (CST) From: "daniel.tian" To: "'Jeff Law'" Cc: , "'Peng Zheng'" , , "'Ian Lance Taylor'" , "'Michael Hope'" , "'Joern Rennecke'" Subject: =?gb2312?B?tPC4tDogSG93IHRvIGRlYWwgd2l0aCB1bnJlY29nbml6YWJsZSBSVEwgY28=?= =?gb2312?B?ZGU=?= Date: Mon, 29 Jun 2009 10:40:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable In-Reply-To: <4A43C3F9.4080508@redhat.com> Message-Id: <20090629093824.716BB3758001@mail.mavrixtech.com.cn> Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-06/txt/msg00667.txt.bz2 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. >=20 > 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 .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 .mode+0 S4 A32])) 11 {load_si} (insn_list:REG_DEP_TRUE 12 (nil)) (nil)) Why there is a crap insn existence: R5 <-- R5??=20 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! =09 Daniel.Tian _______________________________________________ Best Regards Daniel Tian Mavrix Technology, Inc. Address=A3=BA200 Zhangheng Road, #3501, Building 3, Zhangjiang Hi-tech Park, Shanghai, P.R.China (201204)=20 Tel:86(21)51095958 - 8125 Fax:86(21)50277658 Email=A3=BAdaniel.tian@mavrixtech.com.cn www.mavrixtech.com