This is the mail archive of the gcc-patches@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]

Re: [RFA] Integrated hashtables take 2


Mark,

I'm thinking of going with this.  This is declared in cpplib.h.

struct cpp_hashnode
{
  /* Takes up space of tree_common.  */
  struct
  {
    PTR chain;
    PTR type;
    char code_and_flags[4];
  } ignore;

  /* And tree_identifier.  */
  struct
  {
    unsigned int len;
    const unsigned char *name;
  } ident;

  unsigned short arg_index;		/* Macro argument index.  */
  unsigned char directive_index;	/* Index into directive table.  */
  unsigned char rid_code;		/* Rid code - for front ends.  */
  ENUM_BITFIELD(node_type) type : 8;	/* CPP node type.  */
  unsigned char flags;			/* CPP flags.  */

  union
  {
    cpp_macro *macro;			/* If a macro.  */
    struct answer *answers;		/* Answers to an assertion.  */
    enum cpp_ttype operator;		/* Code for a named operator.  */
    enum builtin_type builtin;		/* Code for a builtin macro.  */
  } value;
};

I'll put something similar in the C front ends as a struct
c_common_identifier, with ignore fields for things used by cpplib.

I'll put an enable-checking-only run-time check in the C front end
that offset_of (rid_code) matches between the two, similarly for len
and name, and that sizeof (cpp_hashnode) == sizeof
(c_common_identifier).  That should be enough.

Agreed?  Please let me know a.s.a.p.  Note that packing everything
into one struct the way we do saves space over what we'd get from,
say, C++ inheritance, since we can save on alignment wastage.

We can try to save more space from the "tree_common" in a later patch,
but I don't want to do too much at once.

Besides, I have a plan to start to virtualize trees I'd like to put to
you.

Thanks,

Neil.


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