This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: scheduler first pass and destructive scheduling of REG_LIBCALL/REG_RETVAL blocks?
- To: Bernd Schmidt <bernds at redhat dot com>
- Subject: Re: scheduler first pass and destructive scheduling of REG_LIBCALL/REG_RETVAL blocks?
- From: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Date: Mon, 2 Apr 2001 13:20:37 +0200
- Cc: <gcc at gcc dot gnu dot org>
- References: <Pine.LNX.4.30.0104021155530.4572-100000@host140.cambridge.redhat.com>
On Monday 02 April 2001 12:57, Bernd Schmidt wrote:
> On Sat, 31 Mar 2001, Franz Sirl wrote:
> > I'm currently tracking an excessive stack usage problem with DImode and
> > inlined functions with gcc-2.95.3 on powerpc with the appended testcase.
> > It turned out that the problem is still present in 3.0 and mainline.
> >
> > What I'm not sure about is whether to *first* scheduler pass (before
> > reload) is allowed to destroy REG_LIBCALL/REG_RETVAL blocks? Are there
> > any rules if so? The documentation is unclear in this respect.
>
> It does happen, and so far we've modified the register allocators when this
> has caused problems.
OK.
> > It seems that the destructive scheduling of these blocks confuses reload
> > and causes the excessive stack usage. In fact, if I add
> > -fno-schedule-insns the stack usage is normal (just n DImode-sized
> > stackslots remain for the inlined return values that we can't currently
> > optimize away), 176 bytes. Otherwise the stackusage is between 560 and
> > more than 3000 bytes. This is deadly for the limited kernel stack space
> > in linux and was triggered by ReiserFS on PPC.
>
> I'm not sure this has anything to do with REG_LIBCALL; it may simply be the
> usual case of the first scheduling pass increasing register pressure too
> much.
Well the big difference betweenn "good" and "bad" behaviour here is that for
the "bad" one REG_LIBCALL is scheduled dozens of insns in front the rest of
the block. Also note that the testcasee uses a _lot_ of these blocks and they
get intermixed in the "bad" case by the scheduler. Also the uses of the stack
in the bad case are mostly useless, a lot of
store-DI-to-stack/load-DI-from-stack sequences directly follow each other.
Franz.