From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30421 invoked by alias); 10 May 2011 17:28:23 -0000 Received: (qmail 30412 invoked by uid 22791); 10 May 2011 17:28:23 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 May 2011 17:28:09 +0000 Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p4AHS80B007357 for ; Tue, 10 May 2011 10:28:08 -0700 Received: from ywg4 (ywg4.prod.google.com [10.192.7.4]) by wpaz1.hot.corp.google.com with ESMTP id p4AHQOM1013778 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 10 May 2011 10:28:07 -0700 Received: by ywg4 with SMTP id 4so2202145ywg.10 for ; Tue, 10 May 2011 10:28:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.200.7 with SMTP id x7mr6958115ybf.298.1305048486865; Tue, 10 May 2011 10:28:06 -0700 (PDT) Received: by 10.151.41.13 with HTTP; Tue, 10 May 2011 10:28:06 -0700 (PDT) In-Reply-To: <20110510161543.GW23480@codesourcery.com> References: <20110510161543.GW23480@codesourcery.com> Date: Tue, 10 May 2011 17:28:00 -0000 Message-ID: Subject: Re: [PATCH] split tree_type, a.k.a. "tuplifying types" From: Diego Novillo To: Nathan Froyd Cc: gcc-patches@gcc.gnu.org, java-patches@gcc.gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org X-SW-Source: 2011-q2/txt/msg00044.txt.bz2 On Tue, May 10, 2011 at 13:15, Nathan Froyd wrot= e: > 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? > +static void > +lto_input_ts_type_common_tree_pointers (struct lto_input_block *ib, > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct data_= in *data_in, tree expr) > +{ > + =C2=A0TYPE_SIZE (expr) =3D lto_input_tree (ib, data_in); > + =C2=A0TYPE_SIZE_UNIT (expr) =3D lto_input_tree (ib, data_in); > + =C2=A0TYPE_ATTRIBUTES (expr) =3D lto_input_tree (ib, data_in); > + =C2=A0TYPE_NAME (expr) =3D lto_input_tree (ib, data_in); > + =C2=A0/* Do not stream TYPE_POINTER_TO or TYPE_REFERENCE_TO. =C2=A0*/ 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. OK, otherwise. Thanks for doing this! Diego.