From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 770 invoked by alias); 10 May 2011 21:13:42 -0000 Received: (qmail 753 invoked by uid 22791); 10 May 2011 21:13:41 -0000 X-SWARE-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 May 2011 21:13:25 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) by mx2.suse.de (Postfix) with ESMTP id 1AEA089471; Tue, 10 May 2011 23:13:23 +0200 (CEST) Date: Tue, 10 May 2011 21:13:00 -0000 From: Michael Matz To: Nathan Froyd Cc: Diego Novillo , gcc-patches@gcc.gnu.org, java-patches@gcc.gnu.org Subject: Re: [PATCH] split tree_type, a.k.a. "tuplifying types" In-Reply-To: <20110510175015.GY23480@codesourcery.com> Message-ID: References: <20110510161543.GW23480@codesourcery.com> <20110510175015.GY23480@codesourcery.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="168427776-983887308-1305062003=:1989" 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/msg00046.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --168427776-983887308-1305062003=:1989 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-length: 1059 Hi, On Tue, 10 May 2011, Nathan Froyd wrote: > > > +  /* 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. That is correct. As soon as we read in a POINTER_TYPE or REFERENCE_TYPE we'll reconstruct the target type's TYPE_{POINTER,REFERENCE}_TO fields as being the trees we just process. Type merging would have to overwrite them anyway, so it actually saves time and space to not stream or reconstruct them, just to have them overwritten during type merging. Ciao, Michael. --168427776-983887308-1305062003=:1989--