This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]