[PATCH] Optimize strchr(x, 0), strcmp("a","b") and strstr("abc","bc")

[Jakub Jelinek]

On Tue, Nov 07, 2000 at 11:29:34PM +0000, Joseph S. Myers wrote:
> On Tue, 7 Nov 2000, Jakub Jelinek wrote:
> 
> > > 4.  For strchr(s1, '\0') you convert it to strlen(s1), I think it is
> > > supposed to be (s1 + strlen(s1)).
> >
> > Again, it is clear how proper tests are necessary (wonder why I haven't seen
> > anything during bootstrap/regression testing).
> 
> The optimizations may have been overridden by glibc's string macros; it
> might be useful (i.e., save me the work :-)) if when producing patches for
> string optimizations you also produce the corresponding patches to glibc
> to stop it attempting to be clever in the cases gcc handles.  (This is
> simplest of course if you cover everything glibc does for a particular
> function.  Proper glibc patches may need ideally to cover the various
> <bits/string.h> files with assembler versions - which include similar
> macros to those in <bits/string2.h> - but probably few people use
> <bits/string.h> which needs -D__USE_STRING_INLINES so fixing
> <bits/string2.h> is more important.)

I know, on the other side I think it can be turned off in glibc in bulkier
patches (like after e.g. complete strstr/strchr/strrchr/strcmp/strncmp
optimizations are done, I can submit a glibc patch to turn it off in glibc).

I'll resubmit my updated gcc patch soon (after it bootstraps and is
regression tested). This one optimizes only strchr(const arg, const int)
case for strchr (plus e.g. strrchr(x, '\0') -> strchr(x, '\0')), so e.g.
glibc's string2.h strchr should be changed to:

#ifndef _HAVE_STRING_ARCH_strchr
extern void *__rawmemchr (const void *__s, int __c);
# define strchr(s, c) \
  (__extension__ (!__builtin_constant_p (s)				\
		  && __builtin_constant_p (c) && (c) == '\0'		\
                  ? (char *) __rawmemchr (s, c)				\
                  : strchr (s, c)))
#endif

so that it leaves strchr("foo", 'o') to gcc but optimizes strchr(bar, '\0')
with something gcc cannot do (__rawmemchr is a glibc thing, using memchr
IMHO does not speed things up (it has to check the end boundary) and using
x+strlen(x) means x has to be stored in a non-call-clobbered register.
I should kill this string2.h strchr optimization completely on sparc and
sparc64 though, the assembly strchr/strrchr already special case second arg
0 and are faster than __rawmemchr.

Actually, as next step I'd like to add strchrM optabs, so that i386 backend
can optimize strchr (it will be actually shorter than strlen).

	Jakub