This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Shrinking INTEGER_CSTs and IDENTIFIER_NODEs
- To: gcc at gcc dot gnu dot org
- Subject: Shrinking INTEGER_CSTs and IDENTIFIER_NODEs
- From: Zack Weinberg <zack at wolery dot cumb dot org>
- Date: Sun, 27 Aug 2000 19:21:57 -0700
So I'm thinking about ways to reduce the size of tree nodes, and it
occurs to me that both INTEGER_CST and IDENTIFIER_NODE structures
don't need all the data in a struct tree_common.
For reference, these are the structs I'm looking at, as defined now.
I've annotated them with their size on 32-bit and 64-bit hardware,
making the normal assumptions about alignment.
struct tree_common /* 12/24 bytes */
{
union tree_node *chain;
union tree_node *type;
ENUM_BITFIELD(tree_code) code : 8;
/* and 22 flag bits */
};
struct tree_int_cst /* 24/48 bytes */
{
struct tree_common common;
struct rtx_def *rtl;
unsigned HOST_WIDE_INT int_cst_low;
HOST_WIDE_INT int_cst_high
};
struct tree_identifier /* 20/40 bytes */
{
struct tree_common common;
int length;
char *pointer;
};
As far as I can tell, the rtl slot of struct tree_int_cst is never
used (except in a couple generic operations on 'c' class trees). It
could just go away. But the interesting observation is that
INTEGER_CST nodes never use the chain slot of tree_common, nor do they
use any of those 22 flag bits. And IDENTIFIER_NODEs never use chain
or type, and only the language specific flags (which could use struct
lang_identifier). [Actually, right now, the IDENTIFIER_NODE hash
table uses the chain slot, but that's going to change Real Soon.]
So a hypothetical tight layout of these would be just
struct tree_small_int_cst /* 8/16 bytes */
{
union tree_node *type;
HOST_WIDE_INT int_cst;
};
struct tree_big_int_cst /* 12/24 bytes */
{
union tree_node *type;
unsigned HOST_WIDE_INT int_cst_low;
HOST_WIDE_INT int_cst_high;
};
struct tree_identifier /* 8+n/12+n bytes */
{
struct lang_identifier *data;
unsigned short hash;
unsigned short length;
char pointer[1]; /* VLA */
}
The point of tree_small_int_cst is that most integer constants fit in
a HOST_WIDE_INT, so there's no point in carrying around two of 'em.
You've probably all spotted the problem by now: There's nowhere to
put the tree code. And adding it back will require adding another
whole word because of alignment, which pretty much kills all the
benefit.
Ideas?
zw