This is the mail archive of the 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]
Other format: [Raw text]

Merging stmt_ann_d into tree_statement_list_node


I am thinking about merging stmt_ann_d into tree_statement_list_node.


tree_statement_list_node is a linked list node defined like so

struct tree_statement_list_node {
  struct tree_statement_list_node *prev;
  struct tree_statement_list_node *next;
  tree stmt;

stmt_ann_d is an annotation for a statement ("stmt" above) that
includes operand cache, the basic block that the statement belongs to,
and various flags among other things.


o We have a 1:1 correspondence between tree_statement_list_node and
  stmt_ann_d.  Why have separate data structures?

o Cache win.  Calling bsi_stmt loads tree_statement_list_node into
  memory, which might in turn bring members of stmt_ann_d into cache.
  Note that it's very common to call bsi_stmt and then do something
  with operand cache while walking statements in a basic block.

o bsi_for_stmt becomes an O(1) operation.  Steven Bosscher says that
  the CFG inliner will hit bsi_for_stmt hard.

o Less memory management overhead.

o One step closer to a flat statement structure (or a tuple form if
  you like).  It's a bit silly that we have GIMPLE, but we still do
  not have a flat structure.

o We can probably remove get_stmt_ann and replace all uses of
  stmt_ann.  No more lazy stmt_ann allocation.


Kazu Hirata

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