On Thu, Sep 26, 2013 at 6:07 PM, Andrew MacLeod <amacl...@redhat.com> wrote: > On 09/25/2013 04:49 AM, Richard Biener wrote: >> >> On Tue, Sep 24, 2013 at 4:39 PM, Andrew MacLeod <amacl...@redhat.com> >> wrote: >>> >>> This larger patch moves all the immediate use and operand routines from >>> tree-flow.h into tree-ssa-operands.h. >>> It also moves the basic phi routines and prototypes into a newly created >>> tree-phinodes.h, or tree-ssa-operands.h if they belong there. >>> And finally shuffles a couple of other routines which allows >>> tree-ssa-operands.h to be removed from the gimple.h header file. >>> >>> of note or interest: >>> >>> 1 - dump_decl_set() was defined in tree-into-ssa.c, but isn't really ssa >>> specific. Its tree-specific, so normally I'd throw it into tree.c. >>> Looking >>> forward a little, its only used in a gimple context, so when we map to >>> gimple_types it will need to be converted to/created for those. If it is >>> in >>> tree.c, I'll have to create a new version for gimple types, and then the >>> routine in tree.c will become unused. Based on that, I figured gimple.c >>> is >>> the place place for it. >>> >>> 2 - has_zero_uses_1() and single_imm_use_1() were both in tree-cfg.c for >>> some reason.. they've been moved to tree-ssa-operands.c >>> >>> 3 - a few routines seem like basic gimple routines, but really turn out >>> to >>> require the operand infrastructure to implement... so they are moved to >>> tree-ssa-operands.[ch] as well. This sort of thing showed up when >>> removing >>> tree-ssa-operands.h from the gimple.h include file. These were things >>> like >>> gimple_vuse_op, gimple_vdef_op, update_stmt, and update_stmt_if_modified >> >> Note that things like gimple_vuse_op are on the interface border between >> gimple (where the SSA operands are stored) and SSA operands. So >> it's not so clear for them given they access internal gimple fields >> directly >> but use the regular SSA operand API. >> >> I'd prefer gimple_vuse_op and gimple_vdef_op to stay in gimple.[ch]. > > > Ugg. I incorporated what we talked about, and it was much messier than > expected :-P. I ended up with a chicken and egg problem between the > gimple_v{use,def}_op routines in gimple-ssa.h and the operand routines in > tree-ssa-operands.h. They both require each other, and I couldn't get > things into a consistent state while they are in separate files. It was > actually the immediate use iterators which were requiring > gimple_vuse_op()... So I have created a new ssa-iterators.h file to > resolve this problem. They build on the operand code and clearly has other > prerequisites, so that seems reasonable to me... > > This in fact solves a couple of other little warts. It allows me to put both > gimple_phi_arg_imm_use_ptr() and phi_arg_index_from_use() into > tree-phinodes.h. > > It also exposes that gimple.c::walk_stmt_load_store_addr_ops() and friends > actually depend on the existence of PHI nodes, meaning it really belongs on > the gimple-ssa border as well. So I moved those into gimple-ssa.c
It doesn't depend on PHI nodes but it also works for PHI nodes. So I'd rather have it in gimple.c. > And finally, it turns out that a lot of files include "tree-flow.h" and > depend on it to include "gimple.h" rather than including it themselves. > Since tree-flow.h is losing its kitchen-sink attribute, and I needed to move > it to the bottom of the #include list for tree-ssa.h, I have temporarily > included gimple.h at the top of tree-ssa.h to make sure it gets hauled in. > When I remove tree-flow.h as the "everyone includes it" file, I'll add > gimple.h in all the appropriate .c files and remove it from tree-ssa.h. It > would have just made this growing patch even more annoying for now. > > Does this seem reasonable? Yes - try leaving walk_stmt_load_store_addr_ops in gimple.c though, if that is technically possible. Otherwise I guess I don't mind. Thanks, Richard. > Bootstraps on x86_64-unknown-linux-gnu and currently running regressions. > > Andrew > > PS Oh and I noticed the macro name for tree-outof-ssa.h wasnt right, so I > changed it too. > > Next I'll diverge into trying to sort through putting all the phi-related > structs and such into tree-phinodes.h