This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 9 Jan 2008 09:45:32 -0000
- Subject: [Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
- References: <bug-34683-14773@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #37 from rguenther at suse dot de 2008-01-09 09:45 -------
Subject: Re: [4.3 Regression] Fortran FE
generated IL pessimizes middle-end IL and analysis
On Wed, 9 Jan 2008, jaydub66 at gmail dot com wrote:
> ------- Comment #36 from jaydub66 at gmail dot com 2008-01-09 09:38 -------
>
> > How does the trunk compare now to the numbers mentioned in comment #16 ?
>
> Compiling with rev. 131414 gives:
>
> -O1 -fstrict-aliasing: 33sec, 438197 kB
> -O2: 97sec, 669637 kB
> -O3: 50sec, 392669 kB
>
> This is of course better than a few days ago (thanks to Richard's patches). But
> it's not even close to the numbers in comment #16.
>
> What worries me about this is not the 33sec compile time (I could live with
> that, if I'd have to), but the really large amount of memory. On a machine with
> only 256MB compiling takes several minutes, due to massive swapping.
>
> Richard:
> You said that the remaining issue is probably not gonna be fixed for 4.3. I
> don't quite see the reason for this, since this apparently *was* fixed at some
> point in the 4.3 trunk (see comment 16).
Yeah, but we won't trade wrong-code bugs for better compile-time here.
I have no idea how practical it is to fix basic-block duplication code
(which is the worst offender regarding compile-time in this circumstances
of too many VOPs).
> Also this would really be a shame since it would make GCC 4.3 practically
> unusable for our project (http://gibuu.physik.uni-giessen.de/GiBUU/).
There is a workaround available - you can use
--param max-fields-for-field-sensitive=0
to disable SFTs, but this may disable useful optimization. This is
the route we want to go with 4.4, addressing the missed optimizations in
different ways.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683