[libc++] Turn off PIE when running libc++ premerge tests.

[cmtice]

Turning off PIE for the LLVM premerge tests gave us an 8-10% run time improvement on Linux. Hopefully it can also improve the libc++ premerge test run times.

[llvmbot]

@llvm/pr-subscribers-libcxx

Author: None (cmtice)

Changes

Turning off PIE for the LLVM premerge tests gave us an 8-10% run time improvement on Linux. Hopefully it can also improve the libc++ premerge test run times.

---

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

1 Files Affected:

• (modified) libcxx/utils/ci/run-buildbot (+1)

diff --git a/libcxx/utils/ci/run-buildbot b/libcxx/utils/ci/run-buildbot
index 57ecf1e49dbf2..3adca747b310e 100755
--- a/libcxx/utils/ci/run-buildbot
+++ b/libcxx/utils/ci/run-buildbot
@@ -148,6 +148,7 @@ function generate-cmake() {
           -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind" \
           -DLIBCXX_CXX_ABI=libcxxabi \
           -DCMAKE_EXPORT_COMPILE_COMMANDS=ON \
+          -DCMAKE_EXE_LINKER_FLAGS="-no-pie" \
           "${@}"
 }
 

[boomanaiden154]

This won't have much of an effect. libc++ doesn't build any binaries as part of their build.

The PIE costs for libc++ come from invoking the compiler (if it is compiled with PIE) during testing, and running the just compiled binaries for execution tests. This won't control whether or not the host compiler is built with PIE (other than for a bootstrapping build, which we only do one of).

Controlling the link flags for execution tests would be done somewhere like

llvm-project/libcxx/test/configs/llvm-libc++-shared.cfg.in

Line 13 in 0e33195

'-nostdlib++ -L %{lib-dir} -Wl,-rpath,%{lib-dir} -lc++'

I already tried disabling PIE on the execution tests on Linux and measured virtually no difference on test runtime. I would think turning off PIE for the host compiler would be even less likely to have any gains as I would imagine a large part of the test time is spent doing standard C++ things like parsing headers, dominating startup time. Profiling there wouldn't hurt though.

[cmtice]

This won't have much of an effect. libc++ doesn't build any binaries as part of their build.

The PIE costs for libc++ come from invoking the compiler (if it is compiled with PIE) during testing, and running the just compiled binaries for execution tests. This won't control whether or not the host compiler is built with PIE (other than for a bootstrapping build, which we only do one of).

Controlling the link flags for execution tests would be done somewhere like

llvm-project/libcxx/test/configs/llvm-libc++-shared.cfg.in

Line 13 in 0e33195

'-nostdlib++ -L %{lib-dir} -Wl,-rpath,%{lib-dir} -lc++'

I already tried disabling PIE on the execution tests on Linux and measured virtually no difference on test runtime. I would think turning off PIE for the host compiler would be even less likely to have any gains as I would imagine a large part of the test time is spent doing standard C++ things like parsing headers, dominating startup time. Profiling there wouldn't hurt though.

Then is there any place in libc++ where you think turning off PIE might help? I thought you said there was, but maybe I misunderstood you..

[boomanaiden154]

Then is there any place in libc++ where you think turning off PIE might help? I thought you said there was, but maybe I misunderstood you..

I thought there was some headroom, but I did the benchmark earlier this week and there was no difference between PIE/no PIE.

Building the libc++ SO with PIC I'm not sure would have any performance benefits and would require other things that we probably don't want (like the large code model).

[cmtice]

Then is there any place in libc++ where you think turning off PIE might help? I thought you said there was, but maybe I misunderstood you..

I thought there was some headroom, but I did the benchmark earlier this week and there was no difference between PIE/no PIE.

Building the libc++ SO with PIC I'm not sure would have any performance benefits and would require other things that we probably don't want (like the large code model).

Ok then I'll just close this PR.