RE: i386 backend

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

>
> But that *is* the point.  You can be *much* more precise in reporting
> *where* the problem is.  If you have been serious about benchmarking
> your code in any way, then it should be clear to you what parts of
> your code are having slowdown problems.  That is what is being asked of
> you, and frankly, it is not too much to ask since this is exactly the
> kind of analysis you should be doing anyway if you are at all worried
> about performance.
>

I am not sure I understand what you mean. I have a pretty deep insight in
where my programs "hotspots" are. I have compiled it with many different
compilers, profiled it with different profilers etc. But how can I tell
where the problem with gcc is from that, when I know nothing about the
internals of a compiler?
The biggest "hotspot" in my program is an evaluation function which uses
appx. 30% of the time, according to profilers. This evaluation function is
mainly integer arithmetics and array lookups, in a very complex way. We're
talking appx. 2000 lines of code for one function that eventually just
returns an int.

> The compiler developers know of many places in which the compiler can
> be improved and the vagaries of the 1386 architecture make it a
> particularly nasty test case for a general purpose compiler targeted
> at a wide variety of machine architectures.  Whether or not the
> problems you are experiencing are known or unknown, simple or complex
> is something that can only be answered if and when you do at least
> some of the work to identify specifics.
>

I still don't know _how_ I should identify the specifics, as I am not a
compiler writer, and have no idea what code is being produced in my specific
case. But since gcc is almost always slower, no matter what it compiles, I
assumed that it was not just one problem, but a generally ineffecient
backend.

David