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

[Joseph Myers <joseph@codesourcery.com>]

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).

-- 
Joseph S. Myers
joseph@codesourcery.com