From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7275 invoked by alias); 17 Jan 2004 17:58:08 -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 7264 invoked from network); 17 Jan 2004 17:58:07 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 17 Jan 2004 17:58:07 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0HHv6l04696; Sat, 17 Jan 2004 12:57:06 -0500 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0HHv6g08998; Sat, 17 Jan 2004 12:57:06 -0500 Received: from dnovillo.cipe.redhat.com (dnovillo.cipe.redhat.com [10.0.0.106]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id i0HHv4Xd016378; Sat, 17 Jan 2004 12:57:05 -0500 Subject: Re: [RFC] Contributing tree-ssa to mainline From: Diego Novillo To: Richard Kenner Cc: "gcc@gcc.gnu.org" In-Reply-To: <10401171331.AA17217@vlsi1.ultra.nyu.edu> References: <10401171331.AA17217@vlsi1.ultra.nyu.edu> Content-Type: text/plain Organization: Red Hat Canada Message-Id: <1074362219.5368.66.camel@frodo.toronto.redhat.com> Mime-Version: 1.0 Date: Sat, 17 Jan 2004 17:58:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg01088.txt.bz2 On Sat, 2004-01-17 at 08:31, Richard Kenner wrote: > If we are to wait for all the possible optimizations (vectorization, > memory hierarchy, loop transformations, etc) to be contributed, we may > have to wait quite a bit longer than if we included the infrastructure > in mainline. > > My threshold wouldn't be "all possible optimizations", but enough of > them to show that the new infrastructure not only is going to meet its > expectations but that it isn't going to need to continue to evolve in > major ways. > Fair enough. You bring up a good point about stability in the infrastructure. I do not think that we will see any major changes now. Perhaps transparent changes that largely don't affect major interfaces. > To me, merely saying that "this is obviously a better approach since > it's more modern and is what the textbooks show" would be a *disadvantage* > of the approach. We need to see evidence that this approach really is better. > We've shown some in this thread. When the discussion dies down, I will follow up with a summary so that we can hopefully make a decision at that point. If there's anything in particular you would be interested to see, please let me know. Thanks. Diego.