From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6077 invoked by alias); 1 Jul 2009 03:02:46 -0000 Received: (qmail 5947 invoked by uid 22791); 1 Jul 2009 03:02:45 -0000 X-SWARE-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,BAYES_50 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; Wed, 01 Jul 2009 03:02:37 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.mavrixtech.com.cn (Postfix) with ESMTP id B377250C9F1A; Wed, 1 Jul 2009 10:59:58 +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 Q9C39nYsqxJy; Wed, 1 Jul 2009 10:59:58 +0800 (CST) Received: from danielshmr (daniel-shmr.actions.com.cn [192.168.95.243]) by mail.mavrixtech.com.cn (Postfix) with ESMTP id 6632E50C9E9A; Wed, 1 Jul 2009 10:59:58 +0800 (CST) From: "daniel.tian" To: "'Jeff Law'" Cc: Subject: RE: How to deal with unrecognizable RTL code Date: Wed, 01 Jul 2009 03:02:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Message-Id: <20090701025958.6632E50C9E9A@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-07/txt/msg00008.txt.bz2 > 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: >=20 > /* This loop scans the entire function each go-round > and repeats until one repetition spills no additional hard regs. */ > for (;;) >=20 > 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? >=20 >=20 > 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. >=20 > 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. */ >=20 > 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. >=20 > Jeff > Actually, you are right. I have traced the GO_IF_LEGITIMATE_ADDRESS. I do reject the memory form like (plus (mem (...))). And my Risc do not support the memory reference like this. You mean I should accept the form in GO_IF_LEGITIMATE_ADDRESS macro? Thanks. =09 Daniel. _______________________________________________ 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