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]

Re: c/900: `gcc -O2' takes 30x as long to compile certain files


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.





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