From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-64038-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 2340 invoked by alias); 4 Dec 2002 19:52:39 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 2328 invoked from network); 4 Dec 2002 19:52:37 -0000
Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186)
  by sources.redhat.com with SMTP; 4 Dec 2002 19:52:37 -0000
Received: from uniton.integrable-solutions.net (localhost [127.0.0.1])
	by uniton.integrable-solutions.net (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id gB4JlKtv023094;
	Wed, 4 Dec 2002 20:47:20 +0100
Received: (from gdr@localhost)
	by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id gB4JlJ2V023093;
	Wed, 4 Dec 2002 20:47:19 +0100
X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f
To: David Edelsohn <dje@watson.ibm.com>
Cc: Diego Novillo <dnovillo@redhat.com>, Mark Mitchell <mark@codesourcery.com>,
   Benjamin Kosnik <bkoz@redhat.com>,
   "pcarlini@unitus.it" <pcarlini@unitus.it>,
   "libstdc++@gcc.gnu.org" <libstdc++@gcc.gnu.org>, gcc@gcc.gnu.org
Subject: Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)
References: <200212041946.OAA22968@makai.watson.ibm.com>
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
In-Reply-To: <200212041946.OAA22968@makai.watson.ibm.com>
Organization: Integrable Solutions
Date: Wed, 04 Dec 2002 11:52:00 -0000
Message-ID: <m3r8cxo9bs.fsf@uniton.integrable-solutions.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2002-12/txt/msg00212.txt.bz2

David Edelsohn <dje@watson.ibm.com> writes:

| >>>>> Diego Novillo writes:
| 
| Diego> I see two possible scenarios regarding optimization:
| 
| Diego> (a) We merge the infrastructure with the optimizers disabled and
| Diego> keep working on them in mainline.  This has the advantage of
| Diego> exposing the code for more testing, but it might disrupt
| Diego> development.
| 
| Diego> (b) We don't merge anything for 3.4, keep working on the branch
| Diego> and merge everything for 3.5 or whenever we close the
| Diego> performance gap.
| 
| Diego> Sometimes I'm more inclined towards (b), it seems safer.
| 
| 	I would prefer (a) because that allows Tree-SSA to be a GCC

Since (a) depends on acceptance of GIMPLE and GENERIC, which are
invasive and quite not yet mature, I would prefer (b) given the
other invasive works already scheduled for 3.4.

-- Gaby