This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: i386 backend
- To: "David Rasmussen" <pinkfloydhomer at yahoo dot com>, "Lee Iverson" <leei at AI dot SRI dot COM>
- Subject: Re: i386 backend
- From: "Tim Prince" <tprince at computer dot org>
- Date: Mon, 19 Mar 2001 20:51:34 -0800
- Cc: <dewar at gnat dot com>, <gcc at gcc dot gnu dot org>
- References: <200103192128.NAA56224@Canada.AI.SRI.COM>
The single most common case of gcc generating slower code than
commercial compilers remains, in the code I continue to examine, the
failure to consolidate pointers which differ by a constant known at
compile time. That appears to be something which should be independent
of architecture, although of course it hurts the i386 much more than the
others. But, I've seen a number of cases where gcc code is close to the
same speed as MSVC++, and icl is only about 15% faster. Not enough
difference for many people to care.
----- Original Message -----
From: "Lee Iverson" <leei@AI.SRI.COM>
To: "David Rasmussen" <pinkfloydhomer@yahoo.com>
Cc: <dewar@gnat.com>; <gcc@gcc.gnu.org>
Sent: Monday, March 19, 2001 1:28 PM
Subject: Re: i386 backend
> In message <ELECLDHLONNAHNIBCAEIIEOFCBAA.pinkfloydhomer@yahoo.com>,
"David Rasm
> ussen" writes:
> >
> >Even if I can't be very precise in pointing out _where_ the problems
is, it
> >should still be recognized as a problem. A very simplistic way of
putting it
> >is: "Why is gcc producing slower code than MSVC++ or Intel C++?". I
know
> >that it is not always the case, but from all the different types of
programs
> >I've compiled, and all the people who I have talked to, it is almost
always
> >the case. So there is room for improvement.
>
> 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.
>
> 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.
>
> ----------------------------------------------------------------------
---------
> Lee Iverson SRI International
> leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
> http://www.ai.sri.com/~leei/ (650) 859-3307
>
>