[llvm-dev] [RFC] Adding a -memeq-lib-function flag to allow the user to specify a memeq function.

[James Y Knight via llvm-dev]

This seems a somewhat odd and overcomplicated way to go about this.

Given that bcmp was required in POSIX until relatively recently, I will
guess that almost all platforms support it already. From a quick check,
glibc, freebsd, netbsd, newlib, and musl all seem to contain it. So,
couldn't we just add bcmp to the runtime function list for those platforms
which support it? And, add an optimization to translate a call to memcmp
into bcmp if it exists?

Of course, it would then also be a good idea to go back to POSIX and
present the performance numbers to make a case for why it was actually a
quite valuable function and should be reinstated into the standard as well.

On Thu, Jan 3, 2019 at 4:30 AM Clement Courbet via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi all,
>
> We'd like to suggest *adding a -memeq-lib-function* flag to allow the
> user to specify a `*memeq()*` function to improve string equality check
> performance.
>
> Right now, when llvm encounters a *string equality check*, e.g. `if
> (memcmp(a, b, s) == 0)`, it tries  to expand to an equality comparison if
> `s` is a small compile-time constant, and falls back on calling `memcmp()`
> else.
>
> This is sub-optimal because memcmp has to compute much more than equality.
>
> We propose adding a way for the user to specify a `memeq` library function
> (e.g. `-memeq-lib-function=user_memeq`) which will be called instead of
> `memcmp()` when the result of the memcmp call is only used for equality
> comparison.
>
> `memeq` can be made much more efficient than `memcmp` because equality
> comparison is trivially parallel while lexicographic ordering has a chain
> dependency.
>
> We measured an very large improvement of this approach on our internal
> codebase. A significant portion of this improvement comes from the stl,
> typically `std::string::operator==()`.
>
> Note that this is a *backend-only change*. Because the c family of
> languages do not have a standard `memeq()` (posix used to have `bcmp()` but
> it was removed in 2001), c/c++ code cannot communicate the equality
> comparison semantics to the compiler.
>
> We did not add an RTLIB entry for memeq because the user environment is
> not guaranteed to contain a `memeq()` function as the libc has no such
> concept.
>
> If there is interest, we could also contribute our optimized `memeq` to
> compiler-rt.
>
> A proof of concept patch for this for this RFC can be found here:
> https://reviews.llvm.org/D56248
>
> Comments & suggestions welcome !
> Thanks,
>
> Clement
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190104/2131f2b4/attachment.html>