From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 599 invoked by alias); 17 Jan 2004 14:30:57 -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 589 invoked from network); 17 Jan 2004 14:30:56 -0000 Received: from unknown (HELO ams005.ftl.affinity.com) (216.219.253.151) by sources.redhat.com with SMTP; 17 Jan 2004 14:30:56 -0000 Received: from coyotegulch.com ([4.4.125.218]) by ams.ftl.affinity.com with ESMTP id <3558454-21216>; Sat, 17 Jan 2004 09:30:26 -0500 Message-ID: <400946FC.7050803@coyotegulch.com> Date: Sat, 17 Jan 2004 14:30:00 -0000 From: Scott Robert Ladd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 MIME-Version: 1.0 To: gcc mailing list Subject: Re: [RFC] Contributing tree-ssa to mainline References: <1074298740.3147.79.camel@frodo.toronto.redhat.com> In-Reply-To: <1074298740.3147.79.camel@frodo.toronto.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg01053.txt.bz2 Diego Novillo wrote: > Now that we are about to enter Stage 1 of 3.5, I wanted to solicit > feedback regarding the merge of the tree-ssa branch into mainline. Thank you for raising this topic! > First and foremost is the obvious question of whether people think that > the whole infrastructure is worth adding to GCC at all. From what we've > discussed in the past few months, the consensus seems to be that it is. > But I think it's important to find out if folks think otherwise. I would like to see tree-ssa become mainline as soon as possible. I see no point in putting major work into gfortran and gomp if that effort is going to continue to be speculative, nor do I see an easy way to implement those features (Fortran 95 and OpenMP) in the current mainline. > 1- The changes in tree-ssa are pretty big. A quick diff against the 3.4 > branchpoint in the gcc directory shows > > 11558 files changed, 161996 insertions(+), 14697 deletions(-), 30494 modifications(!) The problem only grows worse with time. It's time to fish or cut bait. > 2- Ada and g77 do not work anymore. The new Fortran 95 front end > replaces g77, though I'm not sure what's the compatibility situation. > There is no replacement for Ada. As it is today, it is impossible to > build an Ada compiler with the branch. The Ada issue is an important one, I think. I don;t know the issues very well; has anyone even considered how the existing Ada compiler might be integrated into SSA? > 3- There are several bug reports opened against the branch (92 as of > today). All branches have bugs. Put SSA in mainline, and we might find more people to work on them. > 4- The branch lags in performance wrt mainline by about 3% in SPECint > and is about 4% faster in SPECfp (take these numbers with a grain of > salt, this is from my daily SPEC runs). I'll try to put together some numbers this weekend based on my independent test suites. > So, there clearly is much work to be done yet. A very conservative view > would be to declare the branch still not ripe for inclusion and wait for > GCC 3.6. As far as I can see, delay gains us nothing but delay. What, precisely, would go into a non-SSA 3.5, beyond bug fixes? Waiting for 3.6 would only increase the difficulty of moving SSA to mainline due to increased "drift". > Pros Mainline is not disrupted with such major changes. > We avoid a possibly lengthy 3.5 cycle. > Other major work can go in without worrying about the new > infrastructure. Other Pros: We would have a working Fortran 95 compiler. OpenMP would get more attention, and might actually see the light of day. I've spoken to some people who might contribute to OpenMP, but who think tree-ssa is too tentative to risk wasting effort. > Another thing to consider is that we need to have peer review for all > the changes done in the branch. The implementation and/or design will > need to be reviewed and may require extensive changes. A good point. Again, the sooner we start, the sooner we're done, and the less that needs to be reworked. ..Scott -- Scott Robert Ladd Coyote Gulch Productions (http://www.coyotegulch.com) Software Invention for High-Performance Computing