RE: i386 backend

["David Rasmussen" <pinkfloydhomer at yahoo dot com>]

> >>>>> "David Rasmussen" writes:
>
> David> But since gcc is almost always slower, no matter what it
> compiles, I
> David> assumed that it was not just one problem, but a generally
> ineffecient
> David> backend.
>
> 	David, the above premise that "gcc is almost always slower" is
> just plain wrong.  As long as you continue to make these unsubstantiated,
> derrogatory statements, you will not get a lot of help from the GCC
> developers.
>

I'm not making these statements to provoke anybody. I'm making them because
it is my experience, both first-hand, in compiling many different types of
programs, and second hand, from people I've communicated with, serious
people who have tried many different compilers, worked intensely with
optimizations etc.

The statement might still be plain wrong. If that is the case, the problem
might not be as big as I imagined, but it is still there, in that most of
what _I_ compile and most of what very different people I talk to, compile,
is slower with gcc.

It's not intended as an attack. It is an observation. If You think I'm
wrong, then I guess You can just ignore me, because I don't have any
extensive testing and many small examples that show the problems I'm talking
about.

> 	If you have a critical function which performs array lookups and
> integer arithmetic, then help us analyze the function to determine if GCC
> is generating the optimal code it can produce.
>

My problem is that I don't even know that it is in this function that gcc
differs from the others. It might another place altogether. I not only have
one critical funtction in this program. The program is rather complex in
terms of optimizing. It is hard to isolate problems to just one function.
There are about 10 critical functions that accounts for 90% of the time, and
they are interrelated in a very complex manner.

David