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

Guillaume Chatelet via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 12 01:35:23 PST 2019


gchatelet added a comment.
Herald added a subscriber: jdoerfert.

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.


I agree. That would be great to see this potential gain converted into an actual real gain for everybody.
I'm working on the optimized internal bcmp, we're still discussing how to contribute this to glibc (since implementation relies heavily on C++ features)

> A couple things I'd worry about, which I think this change is doing properly, but just to double check:
> 
> - I assume that with -ffreestanding, this will be disabled.
> - Some folks avoid -ffreestanding, even though they have a freestanding implementation (sigh). For them, I assume -fno-builtin=bcmp will also disable this.

Unfortunately using LLVM's `-ffreestanding` doesn't seems to conform to the standard <https://en.cppreference.com/w/cpp/freestanding>, so it's already broken in a way.
Clang considers mem* to be a required part of freestanding. Using `-nostdlib` and `-ffreestanding` doesn't mean that Clang and LLVM won't use those functions, it means that you're responsible for providing them.
e.g. passing a big struct by value with `-ffreestanding` will call memcpy in both C <https://godbolt.org/z/gxVCIu> and C++ <https://godbolt.org/z/TJDHh1>

That said, I agree it's better to disable `bcmp` for `-ffreestanding`.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56593





More information about the llvm-commits mailing list