This is the mail archive of the gcc@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]
Other format: [Raw text]

Re: gcc compile-time performance


In article <1021744934.645.16.camel@sonja.de.interearth.com> you write:

>So what? We're basically talking about sacrifying compile time for run
>time. If you don't need the new features of GCC 3.x or whatever then
>don't use it and stick to older versions if compilation gets to slow on
>old machines; you can still use a newer gcc for the final compilation if
>you want maximum performance.

Doesn't work. You invariably run into programs you wish to use that need
the newer features. Or you run into bugs that are fixed in newer versions
where the fix is not backported into older version.

For instance, we run a mutant variation of gcc 2.95.3 in OpenBSD. Things
like, oh, making setjump/longjump exception handling work with a reasonable
cost is one of these things that was fixed *after* 2.95.x was released, and
it took literally forever to backport it to 2.95.3.

We also have some custom i386 peephole to make stack management less ludicrous
(and to win a few VERY valuable bytes on bootstrap floppies). Again, this
is stuff that only exists in mainline 3.0, and that I had to beg for to get
a patch for that would work with 2.95...

Just two examples that come to mind.

Along with the fact that (gasp) gcc is buggy on some platforms, or in some
circumstances, some of these bugs are arch-dependent. Some aren't.  And
having several distinct compilers in existence is the best way to run into
ALL of these bugs instead of a compiler-specific set of them.

If things were ideal, all bugs would be reported. In real life, some bugs
are not reported, because it is kind of pointless to say `when the kernel
is compiled with this version of gcc on this arch, it panics at start. we
haven't been able to pinpoint the exact area where it borked.'

I've also seen a few bugs being closed because they `were similar to another
reported bug', and I've already complained about that on this list (because
in at least one instance, the bugs were not provably the same, were not
reported on the same machine, and the analysis in one bug-report was clearly
deficient. Guess which bug-report won ? that's right, the one on linux. Not
the one where most of the analysis had been done.


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