GCC 3.3 compile speed regression - AN ANSWER

[Michel LESPINASSE]

On Wed, Feb 12, 2003 at 06:29:41PM +0100, Jan Hubicka wrote:
> My common experience is that such a large speedups often comes from very
> simple changes (better memcpy implementation, inlining of one particular
> function or so).  Not sure whether it is the case of kernel code that is
> well hand optimized, but usually it is not that dificult to make GCC to
> do similar trick.

That seems to be true of large slowdowns as well. When I started
compiling libmpeg2 and liba52 with gcc 3.2, initially there was a
large-ish slowdown, on closer analysis it turned out that it was
mainly due to two factors, i.e. incorrect aliasing of the functions I
wanted aliased, and the memset function that had gotten twice
slower. I think you Jan improved the memset thing after I reported it,
the fact the inline keyword does not force inlining anymore in C code
is still a bug in my opinion though. (I worked around it by using
__attribute__ ((__always_inline__)) )

Now with these small changes gcc 3.2 actually generates faster code
for me - but my experience is that I had to work around a few gcc 3.2
performance quirks in order to reap the benefits of moving to it.

Hope this helps,

-- 
Michel "Walken" LESPINASSE
Is this the best that god can do ? Then I'm not impressed.