Re: Merging stmt_ann_d into tree_statement_list_node

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

Hi Andrew,

> It will also involve figuring out what to do with DOM, which has some
> hacks via a call to create_ssa_artficial_load_stmt() which causes a
> non-stmt to have a stmt annotation and operands created for it.  I've
> been bugging Diego to replace the parts of DOM which use this so we can
> remove the hideous abberation, but it still exists at this point. 
> 
> I believe DOM uses the routine to create a dummy expression for a store
> which looks like a load. This load is then entered into the equivalency
> tables such that the store of the expression also shows up as a load
> allowing subsequent loads to be subsumed.  Or something like that
> anyway.  Bottom line is it creates a stmt annotation and operands for an
> expression which is not in any stmt list.

Does this standalone stmt_ann end up in the instruction stream?  That
is, are we going to have a statement as a part of a basic block whose
stmt_ann is the one created in create_ssa_artficial_load_stmt?

If not, I guess we can let DOM do what it wants to do because I am
currently thinking about simply embedding stmt_ann into
tree_statement_list_node like so.

struct tree_statement_list_node
  GTY ((chain_next ("%h.next"), chain_prev ("%h.prev")))
{
  struct tree_statement_list_node *prev;
  struct tree_statement_list_node *next;
  tree stmt;
  struct stmt_ann_d ann;
};

Though leaving this standalone stmt_ann as isn't probably the cleanest
thing to do.  Eventually, I want to completely hide
creation/destruction of stmt_ann from applications (or optimizers if
you like) of the infrastructure.

If this standalone stmt_ann does end up in the instruction stream, we
could structure-copy stmt_ann for the time being (yuck!).

Kazu Hirata