From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1149 invoked by alias); 30 Jan 2002 19:33:09 -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 1041 invoked from network); 30 Jan 2002 19:33:03 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 30 Jan 2002 19:33:03 -0000 Received: from porcupine.cygnus.com (cse.sfbay.redhat.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id LAA23922 for ; Wed, 30 Jan 2002 11:33:00 -0800 (PST) Received: from porcupine.cygnus.com (law@localhost) by porcupine.cygnus.com (8.11.6/8.11.6) with ESMTP id g0UJUQf12763; Wed, 30 Jan 2002 12:30:26 -0700 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: Greg McGary cc: gcc@gcc.gnu.org Subject: Re: condition codes, haifa-sched and virtual-stack-vars Reply-To: law@redhat.com From: law@redhat.com In-reply-to: Your message of Wed, 30 Jan 2002 11:59:59 MST. <200201301859.g0UIxx606426@kayak.mcgary.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Jan 2002 12:42:00 -0000 Message-ID: <12762.1012419024@porcupine.cygnus.com> X-SW-Source: 2002-01/txt/msg01937.txt.bz2 In message <200201301859.g0UIxx606426@kayak.mcgary.org>, Greg McGary writes: > I have a GCC port to a custom RISC that uses condition codes in an > explicit register (doesn't use cc0). GCC generates bogus code when > expanding an inline. One of the inline's args is the address of an > automatic, so it is passed to the inline as a move from > virtual-stack-vars to a pseudo. Later, there's a conditional branch > on bitfield test that expands as bitfield-extract (shift + and), > comparison wtih zero, and branch. All harmless so far. > > Haifa-sched schedules the move from virtual-stack-vars between the > bitfield test sequence and the branch. Later, global-reg alloc > instantiates virtual-stack-vars as an offset from FP, so the move > mutates into an add of fp+offset, clobbering the condition codes > computed earlier in the bitfield test. > > One idea for a localized bandaid is to make the machine-description > wrap moves from virtual-stack-vars in a parallel that has a clobber > CC_REGNUM. Another idea is to manipulate scheduling parameters so > that haifa doesn't schedule anything between CC set and CC use. > (I haven't yet looked at if/how this can be done.) > > What's a better way to fix it? If arithmetic clobbers the register, then that needs to be reflected in the RTL for arithmetic. Otherwise you're going to run into all kinds of problems due to missing critical data dependency information in the scheduler. jeff > > Thanks, > Greg