cvs commit: src/lib/libc/amd64/string Makefile.inc bcmp.S memcmp.S

[David Schultz]

On Fri, Apr 08, 2005, Alan Cox wrote:
> On Fri, Apr 08, 2005 at 12:03:58PM -0400, David Schultz wrote:
> > On Fri, Apr 08, 2005, Alan Cox wrote:
> > > On Fri, Apr 08, 2005 at 05:15:55AM +0000, Alan Cox wrote:
> > > > alc         2005-04-08 05:15:55 UTC
> > > > 
> > > >   FreeBSD src repository
> > > > 
> > > >   Modified files:
> > > >     lib/libc/amd64/string Makefile.inc 
> > > >   Added files:
> > > >     lib/libc/amd64/string bcmp.S memcmp.S 
> > > >   Log:
> > > >   Add machine-specific, optimized implementations of bcmp and memcmp.
> > > >   
> > > >   PR: 73111
> > > >   Submitted by: Ville-Pertti Keinonen <will at iki.fi> (taken from NetBSD)
> > > >   MFC after: 3 weeks
> > > >   
> > > >   Revision  Changes    Path
> > > >   1.2       +1 -1      src/lib/libc/amd64/string/Makefile.inc
> > > >   1.1       +25 -0     src/lib/libc/amd64/string/bcmp.S (new)
> > > >   1.1       +41 -0     src/lib/libc/amd64/string/memcmp.S (new)
> > > 
> > > It is worth noting that by default the current version of gcc
> > > automatically inlines its own implementation of these functions.  That
> > > implementation is slower than this new libc implementation for strings
> > > of non-trivial length.
> > 
> > IIRC, gcc only inlines these in special cases, e.g. if it knows
> > the length or contents of one of the strings.  But this may have
> > changed.
> 
> Yes, however, for bcmp and memcmp the length is given as a parameter
> and thus is always known.  The surprising fact is that the length does
> not have to be a constant for inlining to occur.  Arguably gcc's
> heuristic for inlining these functions should require the length to be
> a small constant. 

Ah, right, I was thinking of strcmp().  Perhaps this should be
filed as a gcc bug.