This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Prune BLOCK_VARs lists in free_lang_data
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Sat, 16 Jan 2016 11:41:31 +0100
- Subject: Re: Prune BLOCK_VARs lists in free_lang_data
- Authentication-results: sourceware.org; auth=none
- References: <20160115110802 dot GD77658 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1601151236370 dot 31122 at t29 dot fhfr dot qr> <20160116102709 dot GD46287 at kam dot mff dot cuni dot cz> <0212CB54-48F8-44D0-8ABB-E0034F39294D at suse dot de>
> >Usually the things stay to make DECL_UID stable across -g and -g0.
>
> Only DECL_UID order needs to be stable I think.
Well, when you remove a reference to a declaration, the DECL_UID order will
change. We stream declarations in the order they are inserted to the encoder
and that depends on specific references from the IL. Creating the decl and
not inserting it to il/optimizing it out early is safe. We do so with debug
statements, block local vars and other stuff.
The difference to non-LTO is that in non-LTO you only need to be sure you
create same decls in the same order. With LTO we need to be sure to keep all
references streamed in the same order. I suppose we could avoid some of it by
streaming DECL_UIDs and merging them same way as we do symbol_table->order but
that will still have fun effects wrt merging.
>
> >This is not
> >the case with LTO,
>
> I don't see how LTO does behave differently here.
>
> so ATM we do not have same codegen with lto and
> >-g/-g0. I
> >guess it is something we can start shooting for once early debug is in.
> >>
> >> That said - improve remove_unused_locals instead please?
I looked into remove_unused_locals and in fact it is removing those decls
aready to some degree, it just keeps all TYPE_DECLs when debug info is on. I
will extend it to skip redundant typedefs.
Honza