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: loop heuristics tweeks


> Hello.
> 
> > Zdenek: I've noticed that you've integrated loop peeling and unrolling into
> > simple loop unrollers.  This looks like neat idea.  What i am worried about
> > is whether it is required for correctness?
> 
> If you speak about the changes in my last patch, yes, it is requiered for
> correctness (it ensures that we may remove exits from unrolled loop except for
> first (last) copy).

So if I unserdtand it correctly, we now have stand alone loop peeling and stand
alone loop unrolling code handling generic loops (for peeling only innermost
loops?)

When we have simple loops if two kinds - ones we know exactly number of
iterations and one we don't. 

In the first case, we do both peeling and unrolling by function
unroll_simple_loop_constant_iterations to avoid pass ordering problem.  This is
confusing, can you put peel into the name as well?  I now see it does contain
code that should peel loop completely when number of iterations is low.  My
change to peel loops makes it to do so earlier with same results at least after
CSE pass.   Perhaps I can revert it.

In other case you compute exit_mod%(max_unroll + 1) and peel according to that
to get number of iterations multiple of max_unroll.  I think this is a bit
wastefull, I think we should try to search number around max_unroll that will
minimize number of peelings necesary.

But it looks like neat idea for cases where unrolled loop iterates few times
(say 2 or 3), as the first iteration can be scheduled into preceeding code,
so I guess this will need some tunning.

With runtime_iterations I see we don't peel at all, instead we do have the code
to get number of iterations multiple of number of unrolings.  This is OK I
guess with my change to peel_loop so we peel runtime_iterations loops with few
measured iterations at average and avoid unrolling copletely.

Later we may want to emit switch-like code to avoid extra conditionals, but
that is not critical at the moment.

Please can you add a bit of documentation to the whole thing, as it is somewhat
confusing right now?  I don't think I am the only who run into trap assuming
that peel_loops is the only place doing loop peeling and the conditionals
in the front decides when we peel or not.

But again I must say that it is really nice piece of code overall :)

Honza
> 
> Zdenek


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