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

[James Y Knight via llvm-dev]

On Mon, Jan 7, 2019 at 5:50 AM Clement Courbet <courbet at google.com> wrote:

> On Fri, Jan 4, 2019 at 12:34 PM James Y Knight via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> 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?
>>>
>>
> That would indeed be much simpler, but this seems brittle to me. The
> approach you're suggesting works for us (google) because we fully control
> our environment, but I'm afraid it will not work for others.
> For example, someone might distribute linux binaries built with LLVM to
> their users, but since there is nothing guaranteeing that bcmp is available
> on the user's libc, they won't be able to run it on their systems.
> Is there a precedent for that approach ?
>

There are many library functions that are only available on some platforms
and not others. LLVM can easily be told which do include it and which do
not, and emit a call only for those which do.

For Glibc Linux, we can be sure that bcmp is available on all systems -- is
is there now, it always has been, and always will be in the future (due to
backwards compatibility guarantees). It's just defined as an alias for
memcmp, however, so there's no advantage (nor, for that matter,
disadvantage) to using it.

But of course it's not _only_ glibc which has it -- it's present in almost
every environment out there.

e.g. for Linux there's also a few other libc implementations that people
use:
musl: includes it, calls memcmp.
uclibc-ng: includes it, alias of memcmp (only if you compile
with UCLIBC_SUSV3_LEGACY, but "buildroot", the way one generally uses
uclibc, does so).
dietlibc: includes it, alias of memcmp.
Android bionic: doesn't include it.

Some other platforms:
RTEMS (newlib): includes it, calls memcmp.
NetBSD: includes it, separate optimized implementation.
FreeBSD: includes it, separate optimized implementation.
Darwin/macOS/iOS/etc: includes it, alias of memcmp.
Windows: doesn't include it.
Solaris: includes it (haven't checked impl).

I do note, sadly, that currently out of all these implementations, only
NetBSD and FreeBSD seem to actually define a separate more optimized bcmp
function. That does mean that this optimization would be effectively a
no-op, for the vast majority of people.

For Google's purposes, if a call to bcmp is emitted by the compiler, you
can of course just override it with a more optimal version. But if you can
show a similar performance win in public code, it'd be great to attempt to
push a more optimized version upstream at least to glibc. Some more precise
numbers than "very large improvement" are probably necessary to show it's
actually worth it. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190107/891b8046/attachment.html>