[clang-repl] Enable native CPU detection by default

[weliveindetail]

We can pass -mcpu=native to the clang driver to let it consider the host CPU when choosing the compile target for clang-repl. We can already achieve this behavior with clang-repl -Xcc -mcpu=native, but it seems like a reasonable default actually.

The trade-off between optimizing for a specific CPU and maximum compatibility often leans towards the latter for static binaries, because distributing many versions is cumbersome. However, when compiling at runtime, we know the exact target CPU and we can use that to optimize the generated code.

This patch makes a difference especially for "scattered" architectures like ARM. When cross-compiling for a Raspberry Pi for example, we may use a stock toolchain like arm-linux-gnueabihf-gcc. The resulting binary will be compatible with all hardware versions. This is handy, but they will all have arm-linux-gnueabihf as their host triple. Previously, this caused the clang driver to select triple armv6kz-linux-gnueabihf and CPU arm1176jzf-s as the REPL target. After this patch the default triple and CPU on Raspberry Pi 4b will be armv8a-linux-gnueabihf and cortex-a72 respectively.

[llvmbot]

@llvm/pr-subscribers-clang

Author: Stefan Gränitz (weliveindetail)

Changes

We can pass -mcpu=native to the clang driver to let it consider the host CPU when choosing the compile target for clang-repl. We can already achieve this behavior with clang-repl -Xcc -mcpu=native, but it seems like a reasonable default actually.

The trade-off between optimizing for a specific CPU and maximum compatibility often leans towards the latter for static binaries, because distributing many versions is cumbersome. However, when compiling at runtime, we know the exact target CPU and we can use that to optimize the generated code.

This patch makes a difference especially for "scattered" architectures like ARM. When cross-compiling for a Raspberry Pi for example, we may use a stock toolchain like arm-linux-gnueabihf-gcc. The resulting binary will be compatible with all hardware versions. This is handy, but they will all have arm-linux-gnueabihf as their host triple. Previously, this caused the clang driver to select triple armv6kz-linux-gnueabihf and CPU arm1176jzf-s as the REPL target. After this patch the default triple and CPU on Raspberry Pi 4b will be armv8a-linux-gnueabihf and cortex-a72 respectively.

---

Full diff: https://github.com/llvm/llvm-project/pull/77491.diff

1 Files Affected:

• (modified) clang/lib/Interpreter/Interpreter.cpp (+1)

diff --git a/clang/lib/Interpreter/Interpreter.cpp b/clang/lib/Interpreter/Interpreter.cpp
index c9fcef5b5b5af1..734fe90d0d89b4 100644
--- a/clang/lib/Interpreter/Interpreter.cpp
+++ b/clang/lib/Interpreter/Interpreter.cpp
@@ -148,6 +148,7 @@ IncrementalCompilerBuilder::create(std::vector<const char *> &ClangArgv) {
   // We do C++ by default; append right after argv[0] if no "-x" given
   ClangArgv.insert(ClangArgv.end(), "-Xclang");
   ClangArgv.insert(ClangArgv.end(), "-fincremental-extensions");
+  ClangArgv.insert(ClangArgv.end(), "-mcpu=native");
   ClangArgv.insert(ClangArgv.end(), "-c");
 
   // Put a dummy C++ file on to ensure there's at least one compile job for the

[vgvassilev]

Thank you for the patch, Stefan! Some of our downstream consumers use that flag for exactly these reasons.

LGTM!

[weliveindetail]

Oh and this matches the default behavior in Orc host detection btw: https://github.com/llvm/llvm-project/blob/release/17.x/llvm/lib/ExecutionEngine/Orc/JITTargetMachineBuilder.cpp#L35

[weliveindetail]

Thanks for the quick review!