BENCHMARK bits/string.h and bits/string2.h optimizations

[Jakub Jelinek <jakub at redhat dot com>]

Hi!

As gcc3 vastly improved and extended builtin stringops optimizations, I'd
like to open the question of which bits/string.h resp. bits/string2.h
optimizations should be disabled for gcc3+ or gcc3.1+.
Attached is a small program + Makefile which tests some stringops
optimizations which bits/string.h and bits/string2.h are trying to do.
Attached are results of running these tests on i686 with -O2 -mcpu=i686
and -O2 -mcpu=i686 -fPIC with trunk gcc.
In the output, gcc means gcc builtins without glibc inlines, nob means the
-fno-builtin without gcc inlines, str means bits/string.h optimizations and
str2 bits/string2.h opts.
Lines marked with * are where gcc is at least as fast as all the others, or
better.
If similar results prove on other arches, IMHO at least string2.h (strcpy, strncat,
strncpy, memset, strstr) are good candidates for
#if !__GNUC_PREREQ(3, 0)
resp. 3,1 depending on whether the same results are found in 3.0 or not.

	Jakub

Attachment: tester.tar.bz2
Description: Binary data

Attachment: o2i686
Description: Text document

Attachment: o2i686pic
Description: Text document