On Tue, Oct 8, 2013 at 2:58 PM, Andrew MacLeod <amacl...@redhat.com> wrote: > On 10/08/2013 08:35 AM, Andrew MacLeod wrote: >> >> On 10/08/2013 07:38 AM, Andrew MacLeod wrote: >>> >>> On 10/08/2013 05:57 AM, Richard Biener wrote: >>>> >>>> Hm. >>>> >>>> Index: loop-iv.c >>>> =================================================================== >>>> *** loop-iv.c (revision 203243) >>>> --- loop-iv.c (working copy) >>>> *************** along with GCC; see the file COPYING3. >>>> *** 62,67 **** >>>> --- 62,68 ---- >>>> #include "df.h" >>>> #include "hash-table.h" >>>> #include "dumpfile.h" >>>> + #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. >>>> >>> 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. >>> >>> 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 loop-niter.[ch]... >>> >>> Andrew >>> >>> >> 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 for rtl. >> >> 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? >> >> Andrew > > heh, make it available, and it will get used :-) It hasn't been this that > way that long.
Well, that's just accessing already computed and preserved max-iteration. That is, the accessors used by loop-*.c should probably be moved to cfgloop.[ch]. Richard. > 2012-04-18 Richard Guenther <rguent...@suse.de> > > PR tree-optimization/44688 > * 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 <j...@suse.cz> > > * 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 > max_loop_iterations_int. > (unroll_loop_constant_iterations): Update > nb_iterations_upper_bound and nb_iterations_estimate. > (decide_unroll_runtime_iterations): Use > estimated_loop_iterations or max_loop_iterations; > (unroll_loop_runtime_iterations): fix profile updating. > (decide_peel_simple): Use estimated_loop_iterations > and max_loop_iterations. > (decide_unroll_stupid): Use estimated_loop_iterations > ad max_loop_iterations. > * loop-doloop.c (doloop_modify): Use max_loop_iterations_int. > (doloop_optimize): Likewise. > * loop-iv.c (iv_number_of_iterations): Use record_niter_bound. > (find_simple_exit): Likewise. > * cfgloop.h (struct niter_desc): Remove niter_max.
