From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9126 invoked by alias); 30 Jan 2002 21:43:07 -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 8993 invoked from network); 30 Jan 2002 21:42:59 -0000 Received: from unknown (HELO faui11.informatik.uni-erlangen.de) (131.188.31.2) by sources.redhat.com with SMTP; 30 Jan 2002 21:42:59 -0000 Received: from faui1a.informatik.uni-erlangen.de (faui1a.informatik.uni-erlangen.de [131.188.31.31]) by faui11.informatik.uni-erlangen.de (8.9.1/8.1.4-FAU) with ESMTP id WAA10267; Wed, 30 Jan 2002 22:42:53 +0100 (MET) From: Ulrich Weigand Received: (from weigand@localhost) by faui1a.informatik.uni-erlangen.de (8.9.1/8.1.172-FAU) id WAA17069; Wed, 30 Jan 2002 22:41:43 +0100 (MET) Message-Id: <200201302141.WAA17069@faui1a.informatik.uni-erlangen.de> Subject: Re: condition codes, haifa-sched and virtual-stack-vars To: greg@mcgary.org Date: Wed, 30 Jan 2002 15:19:00 -0000 Cc: gcc@gcc.gnu.org X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg01949.txt.bz2 Greg McGary wrote: >Here's a summary of mutations, by optimizer phase. [snip reload generating addsi insn clobbering CC] >Things would have been OK if the stack var weren't the first one, >so that it got an offset in 00.rtl, and the associated clobber. >Maybe we shouldn't emit bare virtual-stack-vars, but rather emit as >plus with 0 offset? I've been fighting exactly this problem on s390 ever since we changed from cc0 to an explicit CC register :-( The problem is that reload simply calls gen_add2_insn whenever it feels like it, without consideration that this might introduce a CC clobber at an inappropriate point ... The only way I've found around this is to use some insn that performs an addition without clobbering CC; on many architectures some sort of 'load-address' instruction can be used for this. E.g. on i386, every addition reload wants to perform appears to fit the 'lea' pattern, so they don't have the problem. On s390, while we do have a load-address pattern, it is somewhat restricted (e.g. it accepts only immediate offsets in the 0..4095 range). I've tried to trick reload into using LA anyway, by providing a generic 'add' pattern and splitters to massage the result into a form acceptable by LA afterward. There might be other options, e.g. converting addsi3 into an expander that generates different code when called while reload_in_progress, or using a secondary input reload to handle PLUS reloads ... If you don't have any sort of load-address instruction, I don't know what to do either. Bye, Ulrich -- Dr. Ulrich Weigand weigand@informatik.uni-erlangen.de