This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Shrinking INTEGER_CSTs and IDENTIFIER_NODEs


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]