This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] split tree_type, a.k.a. "tuplifying types"
On Tue, May 10, 2011 at 02:28:06PM -0300, Diego Novillo wrote:
> On Tue, May 10, 2011 at 13:15, Nathan Froyd <froydnj@codesourcery.com> wrote:
> > Other types can of course be shrunk, but the memory savings from doing
> > so will be negligible
>
> Have you done any measurements on the potential savings?
Only back-of-the-envelope. I will try to get some numbers after we
start saving memory. :)
> > +static void
> > +lto_input_ts_type_common_tree_pointers (struct lto_input_block *ib,
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct data_in *data_in, tree expr)
> > +{
> > + ?TYPE_SIZE (expr) = lto_input_tree (ib, data_in);
> > + ?TYPE_SIZE_UNIT (expr) = lto_input_tree (ib, data_in);
> > + ?TYPE_ATTRIBUTES (expr) = lto_input_tree (ib, data_in);
> > + ?TYPE_NAME (expr) = lto_input_tree (ib, data_in);
> > + ?/* Do not stream TYPE_POINTER_TO or TYPE_REFERENCE_TO. ?*/
>
> Add some wording as to why not? This was copied from existing
> comments, but I do not remember why we were doing this. Not too
> critical, anyway.
I'm not entirely sure; I'm not intimately familiar with how LTO
streaming works. lto.c's lto_ft_type and lto_ft_common purport to
recreate TYPE_{POINTER,REFERENCE}_TO, but I don't immediately see how
that's supposed to work. I can imagine that we ought to be able to
recreate those fields after reading everything in, and that's why don't
stream them; I just don't know where that's done.
-Nathan