Re: [PATCH] split tree_type, a.k.a. "tuplifying types"

[Nathan Froyd <froydnj@codesourcery.com>]

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