From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25059 invoked by alias); 11 May 2011 09:03:15 -0000 Received: (qmail 25042 invoked by uid 22791); 11 May 2011 09:03:15 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 May 2011 09:02:59 +0000 Received: by wwi18 with SMTP id 18so4109948wwi.2 for ; Wed, 11 May 2011 02:02:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.182.129 with SMTP id cc1mr5037405wbb.10.1305104577819; Wed, 11 May 2011 02:02:57 -0700 (PDT) Received: by 10.227.20.74 with HTTP; Wed, 11 May 2011 02:02:57 -0700 (PDT) In-Reply-To: <20110510175015.GY23480@codesourcery.com> References: <20110510161543.GW23480@codesourcery.com> <20110510175015.GY23480@codesourcery.com> Date: Wed, 11 May 2011 10:01:00 -0000 Message-ID: Subject: Re: [PATCH] split tree_type, a.k.a. "tuplifying types" From: Richard Guenther To: Nathan Froyd Cc: Diego Novillo , gcc-patches@gcc.gnu.org, java-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-05/txt/msg00814.txt.bz2 On Tue, May 10, 2011 at 7:50 PM, Nathan Froyd wr= ote: > On Tue, May 10, 2011 at 02:28:06PM -0300, Diego Novillo wrote: >> On Tue, May 10, 2011 at 13:15, Nathan Froyd w= rote: >> > 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. =A0I 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, >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 struct data_in *data_in, tree expr) >> > +{ >> > + =A0TYPE_SIZE (expr) =3D lto_input_tree (ib, data_in); >> > + =A0TYPE_SIZE_UNIT (expr) =3D lto_input_tree (ib, data_in); >> > + =A0TYPE_ATTRIBUTES (expr) =3D lto_input_tree (ib, data_in); >> > + =A0TYPE_NAME (expr) =3D lto_input_tree (ib, data_in); >> > + =A0/* Do not stream TYPE_POINTER_TO or TYPE_REFERENCE_TO. =A0*/ >> >> Add some wording as to why not? =A0This was copied from existing >> comments, but I do not remember why we were doing this. =A0Not 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. =A0I 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 >