To: eliz AT is DOT elta DOT co DOT il
Cc: gcc AT gcc DOT gnu DOT org, djgpp-workers AT delorie DOT com
References: <2 DOT 7 DOT 9 DOT 181SX DOT H8JVM1 AT pauzner DOT dnttm DOT ru>
    <2561-Sat11Jan2003175230+0200-eliz AT is DOT elta DOT co DOT il>
    <2 DOT 7 DOT 9 DOT 1HLH DOT H8K8TU AT pauzner DOT dnttm DOT ru>
Message-Id: <2.7.9.WQJB.H8KFN8@pauzner.dnttm.ru>
From: "Leonid Pauzner" <uue AT pauzner DOT dnttm DOT ru>
Date: Sat, 11 Jan 2003 23:01:56 +0300 (MSK)
X-Mailer: dMail [Demos Mail for DOS v2.7.9]
Subject: Re: gcc 3.2.1 optimizer degradation (strlen, -O2)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

> 11-Jan-2003 17:52 Eli Zaretskii wrote:
>>> From: "Leonid Pauzner" <uue AT pauzner DOT dnttm DOT ru>
>>> Date: Sat, 11 Jan 2003 15:49:13 +0300 (MSK)
>>>
>>> It turns out that the libc strlen() function (compiled with -O2)
>>> became nearly 2 times slower when I switched from gcc 2.95.3 to gcc 3.2.1
>>> on a Pentium machine.

>> Are you sure you get the library strlen?  IIRC, GCC provides its own
>> inline versions of some functions, and I think strlen is one of them.

>> Examining the code (use the -S switch to GCC to produce it) should
>> show you whether my guess was true.

[I was wrong in my previous post, lost -O2]
You are right.
2.95 do inline strlen(), while 3.2.1 is not.
Nevertheless I got the following results in my test:

gcc321 -O2
strlen.c   20 sec
strlen2.c  17 sec
(library?) 14 sec

gcc295 -O2
strlen.c   16 sec  (main.c was compiled without -O)
strlen2.c  11 sec  (main.c was compiled without -O)
(builtin)   8 sec

So the difference exists but not that dramatic.