Re: Merging stmt_ann_d into tree_statement_list_node

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

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