This is the mail archive of the
mailing list for the GCC project.
Re: [patch] Add tree-ssa-loop.h and friends.
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 08 Oct 2013 08:58:42 -0400
- Subject: Re: [patch] Add tree-ssa-loop.h and friends.
- Authentication-results: sourceware.org; auth=none
- References: <524CD236 dot 1010009 at redhat dot com> <CAFiYyc2VdYFwQssxnKHcA9k8hnKWPgrxFV7Hra-MawVSJio0Xw at mail dot gmail dot com> <5252B9AF dot 8050103 at redhat dot com> <CAFiYyc3WDepCAH_SSMEJrkVmMXqFdJUsjL8buvs8+Dm2-Ez76g at mail dot gmail dot com> <5253EEB2 dot 6030600 at redhat dot com> <5253FC21 dot 1020602 at redhat dot com>
On 10/08/2013 08:35 AM, Andrew MacLeod wrote:
heh, make it available, and it will get used :-) It hasn't been this
that way that long.
On 10/08/2013 07:38 AM, Andrew MacLeod wrote:
I just took a quick stab at it... I think its pretty involved and
someone with better loop comprehension should probably look at the
followup of removing that requirement.
estimate_numbers_of_iterations_loop() in particular uses last_stmt(),
so it requires gimple.. and there is sprinkling of gimple specific
stuff all through it... I have no idea how this is suppose to work
On 10/08/2013 05:57 AM, Richard Biener wrote:
we've got a bit of a mess in a number of places... I've cleaned up a
few of the easy ones I found.
*** loop-iv.c (revision 203243)
--- loop-iv.c (working copy)
*************** along with GCC; see the file COPYING3.
*** 62,67 ****
--- 62,68 ----
+ #include "tree-ssa-loop-niter.h"
loop-iv.c is RTL land (likewise loop-unroll.c and loop-unswitch.c),
why do they need tree-ssa-loop-niter.h?
Apart from that the patch is ok.
This file is required for record_niter_bound(),
max_loop_iterations_int() and estimated_loop_iterations_int().. so
all bounds estimations. There was enough of an infrastructural
requirement for these routines within the file that I decided it was
beyond the scope of what I'm doing at the moment to split them out.
Eventually I'd like to break this up into modules and make sure that
thing aren't creeping in from the wrong places, and restructure a
bit... Loop suffer from that (like here), cfg has a couple of places
where either rtl or generic cfg routines care calling into a routine
that can understand SSA. I noted one in one of the earlier patches
that I'll have to get back to. This sort of thing has in fact
prompted me to start looking now at our include web and what should
be within the logical modules so we can more easily identify these
sorts of things.
Too many things to clean up!! I think I could be doing this sort of
thing for the next 8 months easily :-)
I'd prefer to come back and revisit this with a followup to try to
split tree-ssa-loop-niter.c into another component, maybe
This is the way it is now, so at least by including that header, it
exposes the hidden problem and either I can revisit it later, or
someone else can tackle that. it seems *really* messy.
OK as is for now?
2012-04-18 Richard Guenther <firstname.lastname@example.org>
* cfgloop.h (record_niter_bound): Declare.
* tree-ssa-loop-niter.c (record_niter_bound): Export.
Update the estimation with the upper bound here...
(estimate_numbers_of_iterations_loop): ... instead of here.
Do not forcefully reset a recorded upper bound.
2012-10-08 Jan Hubicka <email@example.com>
* loop-unswitch.c (unswitch_single_loop): Use
estimated_loop_iterations_int to prevent unswitching when loop
is known to not roll.
* loop-unroll.c (decide_peel_once_rolling): Use
nb_iterations_upper_bound and nb_iterations_estimate.
estimated_loop_iterations or max_loop_iterations;
(unroll_loop_runtime_iterations): fix profile updating.
(decide_peel_simple): Use estimated_loop_iterations
(decide_unroll_stupid): Use estimated_loop_iterations
* loop-doloop.c (doloop_modify): Use max_loop_iterations_int.
* loop-iv.c (iv_number_of_iterations): Use record_niter_bound.
* cfgloop.h (struct niter_desc): Remove niter_max.