This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [PATCH] split tree_type, a.k.a. "tuplifying types"
- From: Michael Matz <matz at suse dot de>
- To: Nathan Froyd <froydnj at codesourcery dot com>
- Cc: Diego Novillo <dnovillo at google dot com>, gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org
- Date: Tue, 10 May 2011 23:13:23 +0200 (CEST)
- Subject: Re: [PATCH] split tree_type, a.k.a. "tuplifying types"
- References: <20110510161543.GW23480@codesourcery.com> <BANLkTikVJc0R9c-KwFqy1qPxt4YgD-T=Lg@mail.gmail.com> <20110510175015.GY23480@codesourcery.com>
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.