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