From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21586 invoked by alias); 16 Oct 2002 20:53:38 -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 21569 invoked from network); 16 Oct 2002 20:53:34 -0000 Received: from unknown (HELO Cantor.suse.de) (213.95.15.193) by sources.redhat.com with SMTP; 16 Oct 2002 20:53:34 -0000 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 367EC16BD8; Wed, 16 Oct 2002 22:53:34 +0200 (MEST) Date: Wed, 16 Oct 2002 14:56:00 -0000 From: Michael Matz To: Mark Mitchell Cc: Geoff Keating , "mrs@apple.com" , "steby@enea.se" , "gcc@gcc.gnu.org" Subject: Re: GCC floating point usage In-Reply-To: <359490000.1034799942@warlock.codesourcery.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-10/txt/msg01003.txt.bz2 Hi, On Wed, 16 Oct 2002, Mark Mitchell wrote: > > (a) Does this affect codegen when the new feature is not enabled? > > Zack's patch does, and it shouldn't. > > I certainly agree that people not using the flag should see no change. > > Why does Zack's patch do that, given his caveat that the sense of the > flag would be reversed so that the flag is off by default? Because it adds an additional insn pattern, with equal predicates as the following one, but with different constraints. This means, that in the case this pattern is activated (which it is by default, given Zacks changed default proposal) it will be preferred, which means, because it only lists float regs in constraints, that float regs will be preferred. Indeed I'm not even sure, that the second pattern will be used at all (if the first is activated), because for insn recognition only predicates are used, which make the first pattern match. Then when reload is running it doesn't rerecognize the insn, and instead reloads all operands of this insn into either float regs or memory, which means, that _no_ integer regs would be used at all for it. That's one of the reason for the requirement that things allowed by the predicates need to have at least one alternative which accepts them. And also that it's suboptimal to have non-disjoint sets of predicates (i.e. which are active at the same time, and match the same insns) with different constraints. Ciao, Michael.