This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: c/900: `gcc -O2' takes 30x as long to compile certain files
- To: Bernd Schmidt <bernds at redhat dot com>
- Subject: Re: c/900: `gcc -O2' takes 30x as long to compile certain files
- From: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Date: Tue, 28 Nov 2000 12:48:04 +0100
- Cc: gcc-patches at gcc dot gnu dot org,gcc-bugs at gcc dot gnu dot org
- References: <200011270950.KAA03529@ixi.eng.ascend.com>
At 15:49 27.11.00, Bernd Schmidt wrote:
>On Mon, 27 Nov 2000 meyering@ascend.com wrote:
>
> > >Synopsis: `gcc -O2' takes 30x as long to compile certain files
>
> > FYI, it began taking much longer to compile that file with -O2
> > some time between Nov 11, (when it worked fine) and Nov 22.
>
>This is because Franz Sirl reverted his accidental checkin of a loop
>optimizer patch by Geoff Keating. I've looked closer at that patch, and
>found that it does fix a bug. Not only can the bug lead to much higher
>compile times as you noticed, it could also probably cause incorrect code
>to be generated.
>
>Basically, when determining whether the destination of a given SET is
>a biv, we scan backwards to find sets of the source (if it's a register).
>Only the first such set should be considered, but we currently scan past
>it and call basic_induction_var recursively each time we see a set of
>the source.
>
>For correctness, we need to terminate the search as soon as we find an
>insn that sets the register, whether or not it's a biv. It seems to me
>that Geoff's patch leaves a small hole open in that code; I've added a
>bit of code that tests for a set inside STRICT_LOW_PART/ZERO_EXTRACT/etc.
>
>Bootstrapped on i686-linux & checked in.
>
>
>Bernd
>
> Based on a patch from Geoff Keating <geoffk@redhat.com>:
> * loop.c (basic_induction_var): If a REG is set from something
> that is not a biv, then the REG is not a biv. Even if it is
> earlier set from something that is a biv.
OK, I applied this to the backport patchset as well, I had Geoff's patch
there before already. This patch has really a nice history now :-).
BTW, can anyone tell me offhand what patches in the mainline fixed:
gcc.c-torture/execute/20000412-2.c
gcc.c-torture/execute/20000917-1.c
gcc.c-torture/execute/align-1.c
? These are the only execution FAIL's I see on powerpc-linux-gnu with
gcc-2_95-branch+V3 patchset compared to the current mainline. Unless the
patches are too invasive, I'm willing to integrate them into the patchset
as well.
Franz.