[patch] Separate immediate uses and phi routines from tree-flow*.h

[Richard Biener]

On Thu, Sep 26, 2013 at 6:07 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
> On 09/25/2013 04:49 AM, Richard Biener wrote:
>>
>> On Tue, Sep 24, 2013 at 4:39 PM, Andrew MacLeod <amacleod@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