This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: i386 inline-asm string functions - some questions
On Sun, Dec 28, 2003 at 10:54:19PM -0500, Andrew Pinski wrote:
> >Zack Weinberg wrote:
> >>I once tried to get Uli to take them out again, with
> >>hard numbers to back me up, but he ignored me.
> >
> >I have absolutely no problem taking out the inlines once gcc is able to
> >perform the same optimizations. Problem is that nobody spent the time
> >so far to complete the task in gcc. As far as I know each function we
> >still have has an advantage over the gcc code.
> >
> >Just look at the inlines to determine what is optimized, do it in gcc,
> >and let me know. Then I'll remove the inline.
>
> We already do more when it comes to removing sqrt and other math
> functions and also
> some string functions we optimize without the need for the string
> instructions.
> In fact GCC does more optimizations on string functions than glibc does
> already.
I think all inlines/macros which are to be removed from bits/string{,2}.h
should be benchmarked first with various constant and variable arguments on
various architectures.
I did it for some routines 2 years ago:
http://sources.redhat.com/ml/libc-hacker/2001-11/msg00035.html
http://sources.redhat.com/ml/libc-hacker/2002-01/msg00091.html
> The functions that GCC does not optimize that glibc does are the
> following:
> memrchr
> strncat (we do sometimes)
> strncmp
> strchr (with a FIXME in GCC)
> strchrnul
> strcspn
> strspn
> strpbrk
> strstr (we do a better job for "a", but we do not do it for the general
> case)
>
>
> The common cases of strcpy, memcpy, etc. we do optimize greatly and as
> the math
> library we do too.
Jakub