On 10/08/2013 06:22 AM, Richard Biener wrote:
On Fri, Oct 4, 2013 at 6:52 PM, Andrew MacLeod <amacl...@redhat.com> wrote:
This patch clears the rest of the improperly located prototypes out of
tree-flow.h. A bit larger than the last few, but I was pushing to clear
this up, and its not quite as bad as it seems :-)
Of interest:
* tree-flow.h now contains *only* prototypes for tree-cfg.c now. Next week
I'll rename it to tree-cfg.h when I visit all the .c files which include
tree-flow.h to see who the true consumers are now.
* tree-ssa-address.c only had one client for get_address_description, and
that required exposing struct mem_address in tree-flow.h. Since that call
was followed by a call to addr_for_mem_ref with the structure, i figured it
was better to create a new funciton which combined that functionality. NOw
the struct is internal only.
* ipa_pure_const.c has only a single export... warn_function_noreturn()
which was only used in one place, tree-cfg.c to implement the
warn_function_noreturn pass. Although the name of the file is not really
appropriate, I moved the pass structural stuff into ipa_pure_const.c and now
there are no exports. I looked at numerous other options, and in the end,
this one is cleanest. There is no other good home for the bits an pieces
that can be shuffled. maybe ipa-func-attr.c would be a better file name
:-P but that is a miniscule issue :_)
* tree-cfg.c had the warn_function_noreturn pass removed from it, but I
relocated the execute_fixup_cfg routine/pass from tree-optimize.c here. It
makes more sense here and that was the only routines being exported from
tree-optimize.c, and tree-cfg was the only consumer.
* tree-dump.h was explicitly prototyping dump_function_to_file() from
tree-cfg.c, presumably to avoid including all of tree-flow.h. I removed that
and include tree-flow.h from tree-dump.c. Seems like a backwards step
until one realizes that tree-flow.h is now the header file for tree-cfg.c.
* tree-ssa-dom.c::tree_ssa_dominator_optimize() was calling
ssa_name_values.release() from tree-ssa-threadedge.c, and was the only
consumer. The call immediately before is to threadedge_finalize_values()
which performs that operation, I deleted the use from tree-ssa-dom.c. I
would like to have made the vec<tree> ssa_name_values static within the file
too, but then the SSA_NAME_VALUE macro to access it would have to make a
call into a function in the .c file to access it, and I don't know what the
performance hit would be... I expect it would be un-noticable to abstract
that out... but I left it for the moment.
* There was a bit of a mess between gimplify.c, gimple.c, and tree.c. In the
end, I
- relocated the tree copying and unsharing routines from gimplify.c to
tree.c. The uses were sporadic throughout the compiler, and weren't always
used by things that should be gimple aware. They were pure tree routines,
so that seemed like an appropriate place for them. Maybe something like
tree-share.[ch] would be better... that could be dealt with during a
tree.[ch] examination.
- force_gimple_operand_gsi_1and force_gimple_operand_gsi were the only
routines in gimplify.c that operated with gimple statement iterators from
gimple.c. The include files had this chicken and egg problem where I
couldn't resolve the ordering very well. IN the end, I decided to relocate
those 2 routines into gimple.c where there is a good understanding of
gimple-iterators. I expect the gimple iterators will be split from
gimple.[ch] when I process gimple.h, so they may be relocatable again later.
- gimple.h declared some typedefs and enums that were gimplification
specific, so I moved those to the new gimplfy.h as well.
This boostraps on x86_64-unknown-linux-gnu and has no new regressions. OK?
graphite.h should be unnecessary with moving the pass struct like you
did for other loop opts. Likewise tree-parloops.h (well, ok, maybe
you need parallelized_function_p, even though it's implementation is
gross ;)). Likewise tree-predcom.h.
fair enough. Yes, I've already seen a few things that madfe my skin
crawl and I had to resist going down a rathole for :-)
unvisit_body isn't generic enough to warrant moving out of gimplify.c
(the only user).
The force_gimple_operand_gsi... routines are in gimplify.c because they ...
gimplify! And you moved them but not force_gimple_operand[_1]!?
OK, let me make the above adjustments, and I'll recreate a patch without
the gimple/gimplfy parts, and re-address that separately. I forget the
details of my include issues there at the moment.
thanks
Andrew
