From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22166 invoked by alias); 17 Jan 2004 00:31:22 -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 22150 invoked from network); 17 Jan 2004 00:31:20 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 17 Jan 2004 00:31:20 -0000 Received: from [192.168.1.7] (account dberlin [192.168.1.7] verified) by dberlin.org (CommuniGate Pro SMTP 4.1.4) with ESMTP-TLS id 5870224; Fri, 16 Jan 2004 19:31:19 -0500 In-Reply-To: <1074298740.3147.79.camel@frodo.toronto.redhat.com> References: <1074298740.3147.79.camel@frodo.toronto.redhat.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <775F5596-4884-11D8-AECF-000A95DA505C@dberlin.org> Content-Transfer-Encoding: 7bit Cc: "gcc@gcc.gnu.org" From: Daniel Berlin Subject: Re: [RFC] Contributing tree-ssa to mainline Date: Sat, 17 Jan 2004 00:31:00 -0000 To: Diego Novillo X-SW-Source: 2004-01/txt/msg00982.txt.bz2 > D. individual passes. > I seriously think re-reviewing each part of tree-ssa as it is merged to the mainline is a bad idea. Their were specific design choices made, and discussed on the mailing list, during design and implementation of tree-ssa over the years. All the passes were reviewed as they were added, and implemented by many of the same people who would be reviewing them now. The only possible thing that reviewing them again could cause is a rehash of the same design issues and tradeoffs that were made in the first place. I strongly believe it should be merged in one piece. Piecemeal merging will also cause nothing but troubles where we've forgotten some small piece of something that was in another file, etc. It also will significantly affect the performance numbers you have posted, since some passes depend on other passes to cleanup their garbage and avoid doing certain things we know have already been done(For example, PRE doesn't do what the dominator optimizers do, on purpose). So you'd have to get them in in the right order anyway, or else someone might see the fact that it doesn't handle something as a "flaw" instead of a design decision. --Dan