LTO merge - free_lang_data

LTO merge - free_lang_data

[Diego Novillo]

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

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.  My second preference would be #3,
which would at least get the code in trunk.

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.


Thanks.  Diego.

[-- Attachment #2: 20090817-free-lang-data.diff.txt.gz --]
[-- Type: application/x-gzip, Size: 23023 bytes --]

Re: LTO merge - free_lang_data

[Richard Guenther]

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.

Re: LTO merge - free_lang_data

[Diego Novillo]

On Mon, Aug 17, 2009 at 12:01, Diego Novillo<dnovillo@google.com> wrote:

> Currently, the pass bootstraps all languages [ ... ]

All *default* languages.  I will add Ada to the mix.


Diego.

Re: LTO merge - free_lang_data

[Ben Elliston]

On Mon, 2009-08-17 at 12:01 -0400, Diego Novillo wrote:

> 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.

I agree with Richard: #2.

Ben