[PATCH] D56593: [SelectionDAG][RFC] Allow the user to specify a memeq function (v5).

Sat Nov 6 12:46:00 PDT 2021

MaskRay added a comment.

In D56593#3113701 <https://reviews.llvm.org/D56593#3113701>, @goldstein.w.n wrote:

> In D56593#1393325 <https://reviews.llvm.org/D56593#1393325>, @jyknight wrote:
>
>> It'd be great to see this somewhat more widely publicized, outside of just the clang community. If libc implementors are aware of the gains and are willing to provide an actually-faster bcmp implementation, it'd be a lot better, than having this optimization that doesn't really optimize anything without users providing their own bcmp implementation.
>
> Tried to add an optimized `bcmp` for GLIBC here <https://marc.info/?t=163157542200002&r=1&w=3>.
>
> It was not well received because `bcmp` is not a standard function. It seems GLIBC supports `bcmp` out of reluctant necessity rather than any desire for it to be fast.
>
> There was agreement that the functionality was useful so GLIBC landed on `__memcmpeq'`to get the functionality. The patches made it to HEAD <https://sourceware.org/git/?p=glibc.git;a=commit;h=44829b3ddb64e99e37343a0f25b2c082387d31a5>
> and will be available starting with the 2.35 release. It declared in "string.h" or can be queried with GLIBC version >= 2.35.
>
> Currently only x86_64 has an optimized version, the rest of the targets still just redirect to `memcmp`.
>
> Working on a patch to add support in LLVM.

I understand and accept the viewpoint that: for glibc, bumping the symbol version for `bcmp` may lead to difficuly-to-debug issues when users try to upgrade glibc.
An ABI-only symbol in the reserved namespace looks good to me.

AFAIK while LLVM has `Triple::isOSLinux` and `Triple::isGNUEnvironment` and there are optimizations dispatching on linux-gnu (well, Apple platforms and some other OSes have such checks)
there is no way detecting the version. The optimizations just assume that a very old glibc version may be used (perhaps 2.10+ or early 2.20+).
In addition, there are many cross compiling users where no version is specified.

The glibc 2.35 availability does not make this optimization exploitable, at least for few (5+?) years :)

---

The original bcmp transformation does make me wonder whether it is a suitable enabled-by-default optimization if neither glibc nor musl actually makes it faster.
One option is to hide such transformation under a `cl::opt` option.

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56593/new/

https://reviews.llvm.org/D56593