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.
