[libc-commits] [PATCH] D101895: [libc] Simplifies multi implementations

Guillaume Chatelet via Phabricator via libc-commits libc-commits at lists.llvm.org
Thu May 6 09:01:36 PDT 2021

gchatelet added a comment.

In D101895#2742165 <https://reviews.llvm.org/D101895#2742165>, @sivachandra wrote:

>> I think we have the following scenarios:
>> - we compile a release and we want to specify which target to compile for (right now this is what the compiler decide is the default).
> In other words, when compiling for the host, we will let the compiler decide the best options?

Compiling for the host means using `-march=native` / `-mcpu=native`. Here I'm just talking about compiling llvm-libc without any options.
That is: when doing a full build, what is the targeted architecture?
AFAIU right now, the compiler decides. With a new version of the compiler the default may change and the targeted architecture as well.
It may be best to explicitly say "I want to compile llvm-libc for haswell when on x86".
AFAICT compilers are being very conservative and by default you get SSE2 only for x86 (check predefined macros without specifying march <https://godbolt.org/z/6WrjzrEEd>).

This is the rationale behind https://reviews.llvm.org/D101991

>> - we compile a release via cross compilation (ARM compiled on x86 or vice versa), so we want to explicitly specify which arch to target.
> In other words, when cross-compiling, we will have to specify certain CMake vars explicitly?

Yes as for the previous bullet point I believe. 
You always want to specify what you are targeting.

>> - we want to run benchmarks on a specific machine and want it to leverage -march/-mtune = native.
> Does it mean that benchmarks are always compiled for the host?

We want to be able to benchmark all the implementations, presumably the host one will perform best.
I removed this part from the patch but we will provide one benchmark per function and per implementation so people can easily test and compare them out.

  rG LLVM Github Monorepo



More information about the libc-commits mailing list