Hello, > I am thinking about merging stmt_ann_d into tree_statement_list_node. > > Background > ---------- > > 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.
guessing from (*) below, you probably just forgot to mention that it also involves changing SSA_NAME_DEF_STMT to point to the tree_statement_list_node rather than the statement itself, otherwise there is no way how to get the annotation for SSA_NAME_DEF_STMT (name)? > Justifications > -------------- > > 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. This is just because CFG inliner is badly written; Honza has already fixed that in his private tree. > 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. > > Thoughts? It is definitely a good idea, IMHO. Zdenek