Re: Merging stmt_ann_d into tree_statement_list_node

[Kazu Hirata <kazu at cs dot umass dot edu>]

Hi Andrew,

> > I might need your help later as a loop optimizer expert.  I just found
> > yesterday that tree-ssa-loop-im.c:schedule_sm is using stmt_ann before
> > a statement proper is linked to a basic block.  Specifically, it
> > creates a statement, attaches a stmt_ann, and puts it on edge.  We
> > probably have to one of the following.
> > 
> > 1) delay the creation of stmt_ann until after a statement is linked,
> > 
> > 2) create a stmt_ann just like we do now, and then copy its contents
> >    to stmt_ann embedded in tree_statement_list_node, or
> > 
> > 3) create a tree_statement_list_node in schedule_sm, which contains
> >    stmt_ann, and link it to a basic block.  (This option would require
> >    bigger changes as we are currently supposed to put a statement in
> >    PENDING_STMT, not a tree_statement_list_node.  Plus, bsi_insert_*
> >    and tsi_link_* stuff all expect a statement.)
> > 
> > Right now I am just instrumenting stmt_ann to see where people are
> > using stmt_ann while a statement is not linked to a basic block.
> 
> These are in fact issues with immediate_uses too.  I fixed the ones I
> found that were causing problems, but the stmt annotation and operands
> should *NOT* be created until a stmt is actually linked the program via
> a bsi_ routine or some such thing. 

Ah, so we should go with 1) above wherever possible.  Once these uses
of stmt_ann are fixed, we can arrange things so that we *CANNOT
POSSIBLY* create stmt_ann and operands (except maybe in
create_ssa_artficial_load).  Then the actual work of embedding
stmt_ann into tree_statement_list_node shouldn't be difficult.

Kazu Hirata