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

2011-05-24 Thread Tom de Vries
On 05/23/2011 05:04 PM, Nathan Froyd wrote: On 05/22/2011 02:24 PM, Tom de Vries wrote: Now that struct tree_type does not exist anymore, 'sizeof (struct tree_type)' generates an error in the following assert in fold_checksum_tree: ... gcc_assert ((sizeof (struct tree_exp) + 5 * sizeof

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

2011-05-23 Thread Nathan Froyd
On 05/22/2011 02:24 PM, Tom de Vries wrote: Now that struct tree_type does not exist anymore, 'sizeof (struct tree_type)' generates an error in the following assert in fold_checksum_tree: ... gcc_assert ((sizeof (struct tree_exp) + 5 * sizeof (tree) = sizeof (struct

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

2011-05-22 Thread Tom de Vries
Hi, Now that struct tree_type does not exist anymore, 'sizeof (struct tree_type)' generates an error in the following assert in fold_checksum_tree: ... gcc_assert ((sizeof (struct tree_exp) + 5 * sizeof (tree) = sizeof (struct tree_function_decl)) sizeof (struct

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

2011-05-11 Thread Richard Guenther
On Tue, May 10, 2011 at 7:50 PM, Nathan Froyd froy...@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 froy...@codesourcery.com wrote: Other types can of course be shrunk, but the memory savings from doing so

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

2011-05-11 Thread Jason Merrill
I'm checking this in to fix build with --enable-gather-detailed-mem-stats. Jason commit 091ac850cf8830722c9bae83232f0d95ccd45b2a Author: Jason Merrill ja...@redhat.com Date: Wed May 11 21:36:09 2011 -0400 * tree.c (type_hash_canon): Use struct tree_type_non_common. diff --git

[PATCH] split tree_type, a.k.a. tuplifying types

2011-05-10 Thread Nathan Froyd
tree_type is a fairly big structure, and several of its fields are overloaded. This means we waste some space, depending on the type, and it's also somewhat confusing as to who uses what. The patch below implements the first step towards tuplifying types: those pieces which all types use have

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

2011-05-10 Thread Mike Stump
On May 10, 2011, at 9:15 AM, Nathan Froyd froy...@codesourcery.com wrote: The patch below implements the first step towards tuplifying types: OK to commit? Ok for Objective parts...

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

2011-05-10 Thread Diego Novillo
On Tue, May 10, 2011 at 13:15, Nathan Froyd froy...@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? +static void +lto_input_ts_type_common_tree_pointers (struct

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

2011-05-10 Thread Tom Tromey
Nathan == Nathan Froyd froy...@codesourcery.com writes: Nathan gcc/java/ Nathan * java-tree.h (TYPE_ARGUMENT_SIGNATURE): Use TYPE_MINVAL. This is ok. Tom

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

2011-05-10 Thread Michael Matz
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