From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27276 invoked by alias); 17 Jan 2004 03:01: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 27269 invoked from network); 17 Jan 2004 03:01:21 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 17 Jan 2004 03:01:21 -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 5870413; Fri, 16 Jan 2004 22:01:21 -0500 In-Reply-To: <200401170217.i0H2HdPM023363@caip.rutgers.edu> References: <1074298740.3147.79.camel@frodo.toronto.redhat.com> <200401170151.i0H1pjEn020723@caip.rutgers.edu> <200401170217.i0H2HdPM023363@caip.rutgers.edu> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6D1B901C-4899-11D8-AECF-000A95DA505C@dberlin.org> Content-Transfer-Encoding: 7bit Cc: gp@suse.de, law@redhat.com, dnovillo@redhat.com, gcc@gcc.gnu.org, gdr@integrable-solutions.net, jsm@polyomino.org.uk From: Daniel Berlin Subject: Re: [RFC] Contributing tree-ssa to mainline Date: Sat, 17 Jan 2004 03:01:00 -0000 To: "Kaveh R. Ghazi" X-SW-Source: 2004-01/txt/msg01004.txt.bz2 On Jan 16, 2004, at 9:17 PM, Kaveh R. Ghazi wrote: >> From: Gabriel Dos Reis >> >> "Kaveh R. Ghazi" writes: >> >> | I would echo Gerald and Joseph's comments about regressions and >> | documentation. (However IMHO, it's up to frontend maintainers to >> | upgrade their bits, so Ada and g77 not working is okay with me.) I >> >> I don't understand that argument. >> >> If someone contributes a patch that suddenly makes a front-end >> non-working, we consider that a non-starter and reject the patch >> until it addresses the "non-working" bits. I do not consider it fair >> to change the mainline in a disruptive way for x front-ends and says >> it is x front-ends maintainers' business to make it work. > > My feeling on this matter is purely in the context of all those > goodies promised. If the new infrastructure is really that good, and > we all agree this is the "future" of GCC, I can live with some > frontends not working and asking it's community to pitch in and > upgrade it. > > Feel free to disagree with me. But remember, they (tree-ssa > advocates) promised a lot. Most of which has been delivered, or at least, is in the process of being delivered: " 1. Better codegen from new and improved optimizations, some easier or only possible in an SSA framework. " Definitely true, as shown by things like SRA. "2. Deletions of major gnarly old parts of GCC which would make maintenance easier. " Various parts of the C expanders (which weren't pretty) have been deleted, and other code is starting to be deleted or significantly reworked to be much simpler. One of the goals was to enable this to occur This goal has *certainly* been successful. The goal of actually doing it is in process, of course. > If it turns out to be just a different > infrastructure, as opposed to a better one, I wouldn't feel the same. It is a better infrastructure. A much better one. I'll leave it to Diego and others to post performance numbers besides SPEC (though i'm happy to do so if necessary).