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
