This is the mail archive of the gcc@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: Does unrolling prevents doloop optimizations?


Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote on 30/06/2007 09:55:45:

> Hello,
>
> > By "this change" I mean just commenting out the check in
> > doloop_condition_get. After applying the patch that introduced DOLOOP
> > patterns for SPU
(http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01470.html)
> > we needed this hack in order to be able to use the doloop_condition_get
to
> > return the register decremented by the branch instruction for any
unrolled
> > loop (The unroller changed originally GE loops to EQ ). Where can this
check
> > be required? Note that we did not touched the similar check in
> > doloop_modify. We tested this on our SPU branch and saw no regressions.
>
> hmmm.... I see now that modulo-sched.c:doloop_register_get uses
> doloop_condition_get, which is why this may affect something.  Anyway,
> changing doloop_condition_get is wrong.  Just teach modulo-sched to use
> number of iterations analysis from loop-iv.c instead of the
> doloop_register_get hack,
>

Here's my understanding.
When the doloop pass looks at a loop, it's doloop_condition_get makes sure
that the closing branch is of a certain form that doloop_modify can handle
(with GE or NE condition only). Changing doloop_condition_get without a
similar change to doloop_modify is expected to trigger some assert in
doloop_modify, or specifically gcc_unreachable in case it sees an EQ
condition.

(A few passes later,) When the sms pass looks at a loop, it apparently sees
this loop closed by an EQ branch, (whose target leaves the loop, and
falling-through to a goto to the beginning of the loop?). This reversal is
presumably related to unrolled loops. Vladimir, it could help if you show
what the EQ closing branch and its target/fallthrough blocks in question
look like.

It doesn't seem that the number of iterations analysis from loop-iv.c deals
with EQ closing branches. One option is for sms to use
doloop_condition_get/loop-iv analysis in their current form, and if failed
check (on our own) for reversed doloop patterns. Another is to try and
reverse the closing branch before calling doloop_condition_get/loop-iv
analysis; any suitable branch reversal facility available?

Ayal.


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