From: Ayal Zaks <ZAKS@il.ibm.com>
To: Kenneth.Zadeck@NaturalBridge.com
Cc: abel@ispras.ru, gcc-patches@gcc.gnu.org, volodyan@gmail.com
Subject: Re: [PATCH][Modulo-sched] Avoid SMS when the candidate loop contains INC instruction
Date: Thu, 26 Jul 2007 18:21:00 -0000 [thread overview]
Message-ID: <OFF239E50B.AB95EFFC-ONC2257324.005D8B73-C2257324.006266CE@il.ibm.com> (raw)
In-Reply-To: <87ejivjft5.fsf@moria.site>
Kenneth Zadeck <Kenneth.Zadeck@NaturalBridge.com> wrote on 26/07/2007
19:22:14:
> > Hello,
> >
> > We decided to break Patch 1 of 2 into sub-patches and insert them
> > gradually. (http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01515.html)
> >
> > This is the first one which avoids performing SMS when the candidate
> > loop contains auto-increment instruction.
> >
> > The testcase attached is inspired from array_constructor_12.f90
testcase.
> >
> > This patch was bootstrapped and tested on ppc64 with -fmodulo-sched
> > flag. (all languages except Ada)
>
> This really cannot be the right thing to do.
>
> If you have a loop that you want to modulo schedule, you should expand
> the autoinc insn back into two insns. If you really find some reason
> why you do not want to do that, then you should not run the auto inc
> finding pass when you enable modulo scheduling.
>
Indeed chickening-out in the face of autoinc's is not the right thing to
do.
The current problem that sms has with autoinc insns is that they have
multiple defs. If one of these defs ends up needing a regmove, we need to
figure out which def it is. That would be the right thing to do. An
alternative is to avoid needing regmoves specifically for such multiple
defs. Currently sms assumes such regmove-needing-defs are the only defs of
their insn, i.e. their lhs. This is also related to the current
restriction to single_set insns. There may be another difficulty for sms
with the destructive nature of autoinc insns: sms may want to rename the
address register used (to hook it up to a regmove) without changing the
register defined.
In any case, there are several fixes that address known issues which we'd
like to push through, making forward progress, noting todo/??? items along
the way, and also providing statistics dumps of which restriction are
encountered in practice.
Ayal.
> Kenny
>
> >
> > :ADDPATCH modulo-sched:
> >
> > OK for mainline?
> >
> > Thanks,
> > Revital
> >
> > 2007-07-26 Vladimir Yanovsky <yanov@il.ibm.com>
> >
> > * modulo-sched.c (sms_schedule): Avoid loops which includes
> > auto-increment instructions.
> >
> > * testsuite/gfortran.dg/sms-1.f90: New test.
>
next prev parent reply other threads:[~2007-07-26 17:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-26 11:06 Revital1 Eres
2007-07-26 16:40 ` Kenneth Zadeck
2007-07-26 18:21 ` Ayal Zaks [this message]
[not found] <OF75BAE848.B63E5DE5-ONC2257323.005B1F08-C2257324.003B7333@LocalDomain>
2007-07-26 11:34 ` Ayal Zaks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=OFF239E50B.AB95EFFC-ONC2257324.005D8B73-C2257324.006266CE@il.ibm.com \
--to=zaks@il.ibm.com \
--cc=Kenneth.Zadeck@NaturalBridge.com \
--cc=abel@ispras.ru \
--cc=gcc-patches@gcc.gnu.org \
--cc=volodyan@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).