From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31593 invoked by alias); 4 May 2005 07:51:15 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 31255 invoked from network); 4 May 2005 07:50:58 -0000 Received: from unknown (HELO mr.tuwien.ac.at) (128.131.2.109) by sourceware.org with SMTP; 4 May 2005 07:50:58 -0000 Received: from ahab.auto.tuwien.ac.at (ahab.auto.tuwien.ac.at [128.130.60.8]) by mr.tuwien.ac.at (8.12.10/8.12.8) with ESMTP id j447oslQ018901; Wed, 4 May 2005 09:50:54 +0200 (MEST) Received: from ahab.auto.tuwien.ac.at (localhost.localdomain [127.0.0.1]) by ahab.auto.tuwien.ac.at (8.12.11/8.12.11) with ESMTP id j447or46010854; Wed, 4 May 2005 09:50:53 +0200 Received: (from mkoegler@localhost) by ahab.auto.tuwien.ac.at (8.12.11/8.12.11/Submit) id j447onaB010842; Wed, 4 May 2005 09:50:49 +0200 Date: Wed, 04 May 2005 08:02:00 -0000 From: Martin Koegler To: James E Wilson Cc: gcc@gcc.gnu.org, Richard Henderson Subject: Re: Incomplete instatitiation of virtual registers Message-ID: <20050504075049.GA8010@ahab.auto.tuwien.ac.at> References: <20050501152531.GA6219@ahab.auto.tuwien.ac.at> <42781AFF.30305@specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <42781AFF.30305@specifixinc.com> User-Agent: Mutt/1.4.1i X-SW-Source: 2005-05/txt/msg00140.txt.bz2 On Tue, May 03, 2005 at 05:44:47PM -0700, James E Wilson wrote: > Martin Koegler wrote: > >I notice, that your last change in function.c forgets virtual > >registers in the RTL in some conditions. In older version (the last I used > >was 20050412), > >this has not happend. > > Patches should go to gcc-patches instead of the gcc list. > > If you want us to continue accepting patches from you, then you need to > fill out a copyright assignment form. > > Recursively calling instantiate_virtual_regs_in_insn does not look > right. We need a better explanation of what is going wrong here. Since > we don't have a copy of your port, you will have to explain in detail > what happens as virtual register instantiation is happening, in order to > explain how this occurs. Normally, we would ask for a testcase, but > that won't work in this case. In that case, I didn't want to get this patch in GCC. In only wanted to inform, that the code forgets some registers and that a rerun of instantiate_virtual_regs_in_insn solves the problem. I don't know, if a bug report is ok in such a case (as I have not reproduced it in a offical version), so I send a mail to Richard Henderson, who did the last change with CC to the GCC list. > It is also possible that this is a bug in your port, if you are > accidentally emitting the virtual register yourself somehow during or > after virtual register instantiation. I discovered the problem, while running a regression test, after I have updated the GCC core. Many compilations failed in refers_to_regno_for_reload_p. It turned out, that the instantiations forget some registers. Adding the two lines of code, it worked again. For that instruction, instantiate_virtual_regs_in_insn enters if(set), then if (GET_CODE (SET_SRC (set)) == PLUS is entered, where if (safe_insn_predicate (insn_code, 1, new) is entered. It then jumps to verify, without changing the destination, because it is MEM expression. After the verify label, no more change of the destination will happen. As far as I have seen, instantiate_virtual_regs_in_insn is called for each instruction only once. Richard Henderson wrote: > I'd like to see the define_insn for {addhi3}. I'm a bit confused as > to how I could have missed iterating over what appears like it ought > to be match_operand 0. (define_insn_and_split "addhi3" [(set (match_operand:HI 0 "regmemptne_operand" "=&rATQ,&rRBU,&rRBU") (plus:HI (match_operand:HI 1 "regmemimmpt_operand" "rATQi,0,rATQI") (match_operand:HI 2 "regmemimmst_operand" "rRBUi,rRBUi,0") ))] ....) I put the patches and new files for the m68hc05 Port again CVS Versions of GCC, Binutils, GDB and newlib of 20050501 at: http://www.auto.tuwien.ac.at/~mkoegler/m68hc05/m68hc05.tar.gz (120k) It is a development shapshot and requires still a lot of work. I have some not yet published documenations about the internals of the GCC port (predicates, constraints,...), if it is needed. Patching and compiling everything, except GCC, is described at http://www.auto.tuwien.ac.at/~mkoegler/index.php/bcus and nested pages. For compiling m68hc05-gcc, a patch (gcc.patch) plus the files in gcc/config/m68hc05 are needed. (In addition to config.sub.patch for adding the processor) mfg Martin Kögler e9925248@stud4.tuwien.ac.at