This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Sun compares their compiler tools to GNU tools
- To: submit-linux-egcs at transmeta dot com
- Subject: Re: Sun compares their compiler tools to GNU tools
- From: torvalds at transmeta dot com (Linus Torvalds)
- Date: 8 Nov 1998 20:27:03 GMT
- Newsgroups: linux.egcs
- Organization: Transmeta Corporation, Santa Clara, CA
- References: <199811071823.KAA07463@yamato.synopsys.com> <k2u30abm8b.fsf@zero.aec.at>
In article <k2u30abm8b.fsf@zero.aec.at>, Andi Kleen <ak@muc.de> wrote:
>
>The problem seems to be that inline functions generate worse code than
>hand expanded macros: KAI C++ expands the inline functions before gcc
>sees it and gets better code.
Gcc inline functions have fairly bad performance, which is sad (and
contrasts against the documentation which claims that inline functions
are as fast as macros - which is definitely not true).
The reason for gcc inline functions being slow _appears_ to be that
inlining is done after CSE and some register allocation. Which is good,
because it means that CSE will nicely CSE inline functions too. I've
used that to good effect to force gcc to CSE stuff it wouldn't otherwise
have found.
However, it's also bad, because it means that CSE will _not_ find common
code inside and outside of a inline function - which is fairly common.
(Note: the above is just from looking at gcc generated code - not from
actually looking at gcc sources. Maybe the code generation issues I've
seen are for some other reason than CSE and regalloc, so take the above
with a grain of salt).
Linus