Re: [patch] Add tree-ssa-loop.h and friends.

[Andrew MacLeod <amacleod at redhat dot com>]

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