From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28555 invoked by alias); 8 Nov 2007 14:02:04 -0000 Received: (qmail 28488 invoked by uid 22791); 8 Nov 2007 14:02:01 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 08 Nov 2007 14:01:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 2705C2AB07E; Thu, 8 Nov 2007 08:59:50 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nsSfnZq7Q0vM; Thu, 8 Nov 2007 08:59:50 -0500 (EST) Received: from [127.0.0.1] (nile.gnat.com [205.232.38.5]) by rock.gnat.com (Postfix) with ESMTP id D87A42AB088; Thu, 8 Nov 2007 08:59:49 -0500 (EST) Message-ID: <47331636.9010308@adacore.com> Date: Thu, 08 Nov 2007 15:13:00 -0000 From: Robert Dewar User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Michael Matz CC: Alexandre Oliva , Richard Guenther , gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Designs for better debug info in GCC References: <84fc9c000711050327x74845c78ya18a3329fcf9e4d2@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2007-11/txt/msg00243.txt.bz2 My general feelings on this subject: 1. I don't think we should care much about the ability to *SET* values of variables in optimized code. You can definitely do without that. So if a variable exists in two places, no problem, just register one of them. 2. It is much more important to have reasonable debugging for most users than the last mile of optimization. For me we should ensure that -O1 is still reasonably debuggable. The switch to GCC 4, at least in the Ada context, has significantly degraded -O1 debugging. I have found for instance that debugging the GNAT compiler itself, -O1 used to be perfectly fine, but now far too many arguments and variables disappear. 3. The quality of code at -O0 is really terrible compared to the competition (at least in the case of Ada), and large scale programs are just too big at -O0 to be practical (there is a big difference between a 50 megabyte image and a 100 megabyte image). So we really cannot rely on using -O0 for debugging. At -O1 we are more than competitive for performance with competing compilers. 4. In any case, most users really prefer to test and debug at the same optimization level that they will use for delivery. As noted above, -O0 is seldom practical for delivery (furthermore the voluminous extra code makes certification at the object level more work). -O1 is a fine compromise from a performance point of view, but needs to be debuggable. 5. Among our users we have relatively few who care about even a factor of 2 in performance, and VERY few who care about 10%. On the other hand we have lots of customers who definitely have severe problems with the lack of debuggability of -O1 code. 5. We have talked sometime about a -Od level or somesuch that would be fully debuggable. That's an interesting idea, but I think in practice it is more reasonable to try to ensure good debugging at -O1. Optimizations that significantly intefere with debugging should be moved to -O2. I think it is fine for -O2 to mean "optimize the heck out of the program, I really care about the last ounce of optimization, and I know debuggability will suffer."