[PATCH 5/5] x86_64: Add evex optimized bcmp implementation in bcmp-evex.S

[Noah Goldstein]

On Mon, Sep 13, 2021 at 11:21 PM DJ Delorie <dj@redhat.com> wrote:

> Noah Goldstein <goldstein.w.n@gmail.com> writes:
> > So I think I was able to fix the build by making a new file in
> glibc/string/bcmp.c
> > and just having bcmp call memcmp
> >
> > Is there another/better way to fix the build?  I don't think it's really
> fair that every
> > arch other than x86_64 should have to pay an extra function call cost to
> use bcmp.
>
> There are at least three...
>
> First, note that bcmp is a weak alias to memcmp already - see
> strings/memcmp.c - which avoids the extra call you mention.
>
> So, you could either move that weak alias into bcmp.c, or arrange for
> bcmp.c to not be needed by the Makefile for non-x86_64 platforms.
> Lastly, an empty bcmp.c wouldn't override the alias in memcmp.c.  I
> think the first would be easiest, although it may be tricky to compile a
> source file that seems to do "nothing".  Also, I suspect liberal use of
> comments would be beneficial for the unsuspecting reader ;-)
>
>
I see.

I was able to get it working with just an empty bcmp.c file but was not able
to move the weak_alias from memcmp.c to bcmp.c

Adding:
```
#ifdef weak_alias
# undef bcmp
weak_alias (memcmp, bcmp)
#endif
```

to bcmp.c gets me the following compiler error:

```
bcmp.c:24:21: error: ‘bcmp’ aliased to undefined symbol ‘memcmp’
```

irrespective of the ifdef/undef and whether I include string.h/manually
put in a prototype of memcmp.

Sorry for the hassle. Build infrastructure, especially in a project as
complex
as this, is a bit out of my domain.


> Alternately, you could change your patch to provide alternate versions
> of memcmp() instead of bcmp(), as glibc's bcmp *is* memcmp.  This is
> what other arches (and x86_64) do:
>

I'm not 100% sure what you mean? memcmp can correctly implement bcmp
but not the vice versa.


>
> $ find . -name 'memcmp*' -print
>
>