This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Add tree-ssa-loop.h and friends.
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 8 Oct 2013 15:18:11 +0200
- 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> <52540182 dot 7060604 at redhat dot com>
On Tue, Oct 8, 2013 at 2:58 PM, Andrew MacLeod <amacleod@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 <rguenther@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 <jh@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.