This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Prune BLOCK_VARs lists in free_lang_data


> > On Tue, 19 Jan 2016, Jan Hubicka wrote:
> > 
> > > Hi,
> > > here is updated patch. It has same effect as the former version.
> > > 
> > > Bootstrapped/regtested x86_64-linux, OK?
> > 
> > But what about the comment?
> > 
> >          We track no
> >          information on whether given type is used or not, so we have
> >          to keep them even when not emitting debug information,
> >          otherwise we may end up remapping variables and their (local)
> >          types in different orders depending on whether debug
> >          information is being generated.  */
> > 
> > which suggests that the TYPE_DECLs somehow "order" remapping
> > of local types and that is somehow important (maybe for VLA
> > types which refer to locals). OTOH local vars are also
> > duplicated in order before copying stmts (which may introduce
> > differences because of seeing debug stmts or not refering to
> > decls/types).
> 
> The original patch is here:
> https://gcc.gnu.org/ml/gcc-patches/2011-01/msg01344.html
> my understand is that it is all about DECL_UID being stable with -g0
> and -g. My patch does not change that becuase I drop ignored and redundant
> typedefs even with -g.

Alexandre, aslo your original mail mentions:
> Anyhow, it seems to me that dropping local type decls from lexical
> scopes doesn't buy us much, and even though it is indeed a sledgehammer,
> as richi put it, this fixes the problem, and I can't envision other
> simpler solutions that wouldn't risk running into the problems mentioned
> above, so...

> Regstrapped on x86_64-linux-gnu and i686-pc-linux-gnu.  Ok to install?


> One solution I do envision, which might help, would be to try to figure
> out which types are unused, and discard those.  Say, scan all variables
> within a lexical scope (including nested blocks), deciding which ones
> can be discarded, and then, as we move out of the nesting, we can
> decide, from last to first, which types are unused, and mark as used
> types refereced from retained variables and other types that are used,
> removing those that, when reached during this backward scan, remain
> marked as unused.  Or something along these lines, taking nested
> functions into account, if needed, and anything else I may have missed
> ;-)

dropping the type_decls definitly buys us a memory with LTO and firefox.  How
hard would be to implement the prunning of dead TYPE_DECLs as you suggest?

Honza
> 
> Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]