From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2209 invoked by alias); 1 Jul 2009 01:57:33 -0000 Received: (qmail 2198 invoked by uid 22791); 1 Jul 2009 01:57:32 -0000 X-SWARE-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,BAYES_00,CHARSET_FARAWAY_HEADER,MIME_CHARSET_FARAWAY,SARE_HEAD_8BIT_SPAM,SARE_SUB_ENC_GB2312,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Jul 2009 01:57:26 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n611vN7g005393; Tue, 30 Jun 2009 21:57:23 -0400 Received: from omfg.slc.redhat.com (vpn-225-40.phx2.redhat.com [10.3.225.40]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n611vLn6015046; Tue, 30 Jun 2009 21:57:22 -0400 Message-ID: <4A4AC2AA.8010708@redhat.com> Date: Wed, 01 Jul 2009 01:57:00 -0000 From: Jeff Law User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: "daniel.tian" CC: gcc@gcc.gnu.org, "'Peng Zheng'" , thomas.liau@mavrixtech.com, "'Ian Lance Taylor'" , "'Michael Hope'" , "'Joern Rennecke'" Subject: Re: =?GB2312?B?tPC4tDogSG93IHRvIGRlYWwgd2l0aCB1bnJlY29nbml6YWJsZQ==?= =?GB2312?B?IFJUTCBjb2Rl?= References: <20090629093824.716BB3758001@mail.mavrixtech.com.cn> In-Reply-To: <20090629093824.716BB3758001@mail.mavrixtech.com.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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-07/txt/msg00002.txt.bz2 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 .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?? > 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