Re: Re: [PATCH 1/5] x86_64: Add support for bcmp using sse2, sse 4_1, avx2, and evex

[Noah Goldstein via Libc-alpha <libc-alpha@sourceware.org>]

On Wed, Sep 15, 2021 at 1:30 PM Joseph Myers <joseph@codesourcery.com>
wrote:

> On Wed, 15 Sep 2021, Noah Goldstein via Libc-alpha wrote:
>
> > > > I do rather like the idea of a __gnu_memeq() that compilers could
> > > > optimize memcmp calls to, when they can prove that the result is used
> > > > only for its truth value.
> > >
> > > Yes, we should use a name in the implementation namespace because even
> > > if we pick an obvious like memequal, it will probably come back under a
> > > different name from the C committee.
> > >
> >
> > +1
> >
> > What would be the steps for getting that into GLIBC?
>
> Define what the exact interface you want is (the exact function type and
> (reserved) name and semantics of the return value and arguments;
> explicitly including details such as whether the full n bytes of each
> argument are required to be mapped into memory even if they compare
> unequal before n bytes).
>
> Discuss it on the libc-coord mailing list (probably include compiler
> mailing lists as well) to get agreement on semantics that are good for
> both libc implementations and for compilers to generate; it's best if this
> interface is acceptable to multiple libc implementations and suitable for
> multiple compilers to generate calls to (when available in libc).
>
> Implement in glibc, across all glibc ports and including all the ABI test
> baseline updates.  If the semantics are such that an alias to memcmp is a
> valid implementation, that probably means adding such an alias to every
> memcmp implementation in glibc (and verifying with build-many-glibcs.py
> that they all build and pass the ABI tests), as well as allowing for
> architectures to add their own separate implementation of the new function
> if they wish.  There should also be execution tests that the new function
> works correctly at runtime (with different alignment, arguments just
> before unmapped pages, etc., as with other string function tests).  If the
> new function is purely an ABI, not an API, it doesn't need user manual
> documentation, however (although there will at least need to be a comment
> giving the detailed semantics that were agreed on libc-coord).
>
>
Is there some documentation for how to effectively use build-many-glibcs.py

I've tried:

$> python3 src/glibc/scripts/build-many-glibcs.py /some/were checkout
gcc-vcs-11
$> python3 src/glibc/scripts/build-many-glibcs.py /some/were host-libraries
$> python3 src/glibc/scripts/build-many-glibcs.py /some/were compilers
$> python3 src/glibc/scripts/build-many-glibcs.py /some/were glibcs

With GLIBC master I'm seeing a ton of failures so I'm not sure how I'm
supposed to actually test my patches.

I've also tried with gcc-vcs-mainline although my guess is that it will
just be a less stable version that could cause unrelated failures.



> --
> Joseph S. Myers
> joseph@codesourcery.com
>