From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4718 invoked by alias); 11 Apr 2010 15:36:34 -0000 Received: (qmail 4707 invoked by uid 22791); 11 Apr 2010 15:36:33 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM X-Spam-Check-By: sourceware.org Received: from mathups.math.u-psud.fr (HELO matups.math.u-psud.fr) (129.175.52.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 11 Apr 2010 15:36:28 +0000 Received: from barah.math.u-psud.fr (barah.math.u-psud.fr [129.175.52.24]) by matups.math.u-psud.fr (Postfix) with ESMTP id 65D417536; Sun, 11 Apr 2010 17:36:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by barah.math.u-psud.fr (Postfix) with ESMTP id 60AF6474117; Sun, 11 Apr 2010 17:36:26 +0200 (CEST) Received: from barah.math.u-psud.fr ([127.0.0.1]) by localhost (barah.math.u-psud.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuWHfvODXEuQ; Sun, 11 Apr 2010 17:36:24 +0200 (CEST) Received: from [IPv6:::1] (topodyn-ng.math.u-psud.fr [129.175.50.33]) by barah.math.u-psud.fr (Postfix) with ESMTP id 85BC5474040; Sun, 11 Apr 2010 17:36:24 +0200 (CEST) Message-ID: <4BC1EC78.4050808@free.fr> Date: Sun, 11 Apr 2010 15:41:00 -0000 From: Duncan Sands User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100404 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eric Botcazou CC: gcc@gcc.gnu.org, Steven Bosscher Subject: Re: dragonegg in FSF gcc? References: <20100409163655.GA25781@bromo.med.uc.edu> <4BC1D647.60902@free.fr> <201004111632.04289.ebotcazou@adacore.com> In-Reply-To: <201004111632.04289.ebotcazou@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-04/txt/msg00193.txt.bz2 Hi Eric, >> As for "negating the efforts of those working on the middle ends and back >> ends", would you complain if someone came up with a new register allocator >> because it negates the efforts of those who work on the old one? If LLVM >> is technically superior, then that's a fact and a good thing, not >> subversion, and hopefully will encourage the gcc devs to either improve gcc >> or migrate to LLVM. > > Well, the last point is very likely precisely what Steven is talking about. > GCC doesn't have to shoot itself in the foot by encouraging its developers to > migrate to LLVM. I hope it was clear from my email that by "gcc" I was talking about the gcc optimizers and code generators and not the gcc frontends. If the dragonegg project shows that feeding the output of the gcc frontends into the LLVM optimizers and code generators results in better code, then gcc can always change to using the LLVM optimizers and code generators, resulting in a better compiler. I don't see how this is gcc the compiler shooting itself in the foot. Of course, some gcc devs have invested a lot in the gcc middle and back ends, and moving to LLVM might be personally costly for them. Thus they might be shooting themselves in the foot by helping the LLVM project, but this should not be confused with gcc the compiler shooting itself in the foot. All this is predicated on gcc-frontends+LLVM producing better code than the current gcc-frontends+gcc-middle/backends. As I mentioned, dragonegg makes it easier, even trivial, to test this. So those who think that LLVM is all hype should be cheering on the dragonegg project, because now they have a great way to prove that gcc does a better job! Ciao, Duncan.