From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 523 invoked by alias); 20 Jan 2004 00:20:44 -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 499 invoked from network); 20 Jan 2004 00:20:43 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sources.redhat.com with SMTP; 20 Jan 2004 00:20:43 -0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id i0K0Kgcb004407 for ; Mon, 19 Jan 2004 16:20:42 -0800 (PST) Received: from relay3.apple.com (relay3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Mon, 19 Jan 2004 16:20:42 -0800 Received: from [17.201.20.186] (gambrinus.apple.com [17.201.20.186]) by relay3.apple.com (8.12.10/8.12.9) with ESMTP id i0K0KgN7000792; Tue, 20 Jan 2004 00:20:42 GMT In-Reply-To: <476C5192-4AD9-11D8-8DB8-000A95DA505C@dberlin.org> References: <10401170324.AA15949@vlsi1.ultra.nyu.edu> <20040119153026.A21678@synopsys.com> <476C5192-4AD9-11D8-8DB8-000A95DA505C@dberlin.org> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <41623779-4ADE-11D8-B36A-000A95D7CD40@apple.com> Content-Transfer-Encoding: 7bit Cc: Joe Buck , s.bosscher@student.tudelft.nl, gcc@gcc.gnu.org, Dale Johannesen , Richard Kenner From: Dale Johannesen Subject: Re: [RFC] Contributing tree-ssa to mainline Date: Tue, 20 Jan 2004 00:20:00 -0000 To: Daniel Berlin X-SW-Source: 2004-01/txt/msg01418.txt.bz2 On Jan 19, 2004, at 3:43 PM, Daniel Berlin wrote: > I'd like to point out that this whole thread is still getting us > somewhere, and not just filling up inboxes. > Seriously though, I think we've reached the point of diminishing > gains. We now know how everyone feels. > It appears that this is "most people are in favor, some people are > against", but everyone seems to have some specific criteria they want > met before merging. > Anyway, It would be more productive if we were to try to concentrate > on a specific set of merge criteria for tree-ssa, than continue to > discuss the benefits or disadvantages of it (since it seems clear the > overwhelming number of people think it has great benefit already) IMO the important question to ask is, will tree-ssa be the basis for 3.5? If the answer to this is yes, I believe we should merge immediately even if the current state is not what we would like it to be. That will reduce everyone's maintenance burden. > I'd also like to point out that tree-ssa is, by various benchmarks > pointed out earlier, in the worst case, slightly slower than the > mainline in compile time, even though it adds *30* optimization > passes. > That's right. > Thirty. > Check tree-optimize if you don't believe me. > That's quite an accomplishment in and of itself if you ask me. It suggests that one pass does not take a lot of time, provided you aren't doing much in that pass. This is in line with my experience (and other people's) on other compilers.