From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26283 invoked by alias); 17 Aug 2009 16:07:39 -0000 Received: (qmail 26270 invoked by uid 22791); 17 Aug 2009 16:07:38 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 17 Aug 2009 16:07:28 +0000 Received: from relay1.suse.de (mail2.suse.de [195.135.221.8]) by mx2.suse.de (Postfix) with ESMTP id B18B7965C0; Mon, 17 Aug 2009 18:07:25 +0200 (CEST) Date: Mon, 17 Aug 2009 16:19:00 -0000 From: Richard Guenther To: Diego Novillo Cc: gcc@gcc.gnu.org Subject: Re: LTO merge - free_lang_data In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: 2009-08/txt/msg00293.txt.bz2 On Mon, 17 Aug 2009, Diego Novillo wrote: > I am merging free_lang_data, which is an IPA pass that scrubs all > types and symbols from any front end language information. > > After free_lang_data all types and symbols are in gimple form. > This form is much leaner in terms of memory utilization and since > it does not rely on the presence of the front end, it can be > streamed to disk for LTO. > > The biggest side-effect right now is that many debug hooks stop > working because the information just isn't there. So part of all > this is to recognize when debug information is requested and > save it so that it can be used from debug hooks. > > Currently, the pass bootstraps all languages but since debug > information is disabled, all the debugging tests in the testsuite > fail. > > Since the patch is rather large and it affects the other LTO > merge activities, I've been thinking about ways of making it > easier and avoid conflicts: > > 1- Keep working on my local tree; combining both free_lang_data and > early debug generation. > > 2- Add free_lang_data to trunk with a gate function that only > triggers it if -g is missing. > > 3- Add free_lang_data to trunk with a gate function that enables > it only if a special flag is given on the command line. > > > My obvious preference is #2 because that will simplify our > merging activities and will also allow wider testing for > free_lang_data in the trunk. I definitely would prefer #2. If it even passes bootstrap-debug (or how it is called - verify that the code generated with/without -g is the same) then IMHO it would be a no-brainer. > My second preference would be #3, > which would at least get the code in trunk. Well - with that reasoning we could simply merge all of LTO now ... which I wouldn't mind either ;) > Other than latent bugs, the main observable difference with this > patch in trunk will be reduced memory consumption at > compile-time, particularly for C++ (free_lang_data removes quite > a bit of cruft). > > I am attaching the WIP patch for reference. I would appreciate > feedback on this plan. I'd say go for #2. #3 doesn't make much sense to me in isolation. Thanks, Richard.