On Mon, 2005-04-25 at 04:48, Zdenek Dvorak wrote: > 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)?
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. Andrew