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

[Richard Guenther <richard.guenther@gmail.com>]

On Tue, May 10, 2011 at 7:50 PM, Nathan Froyd <froydnj@codesourcery.com> wrote:
> 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.

Yes, we're re-creating them to avoid streaming all pointer types that might
be unused before streaming.

One nit:

+struct GTY(()) tree_type_non_common {
+  struct tree_type_with_lang_specific common;

shouldn't that field be named w_lang_specific or something like that,
instead of re-using common?

Richard.

> -Nathan
>