Re: LTO merge - free_lang_data

[Richard Guenther <rguenther at suse dot de>]

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.