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
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.

- Raw text -