From 87f31fa06cd3d604dfbe29597676836bdca4c857 Mon Sep 17 00:00:00 2001 From: Filip Leonarski Date: Sun, 2 Aug 2026 20:32:14 +0200 Subject: [PATCH] ci: record why LTO is a flag and not CMAKE_INTERPROCEDURAL_OPTIMIZATION The CMake variable is the tidier spelling and would cover the MSVC job too, so it is the obvious thing to reach for and worth saying why it was not. It builds and links, CUDA included - and it does not reach .cu targets either way, so there is no -dlto risk on either route. But it optimises less: 396.9 G retired instructions against 384.9 G for -flto=auto, three runs each, with a 0.45% run-to-run spread, so a 3% gap is not measurement luck. Of 107 static libraries the two routes agree within 5% on 105; the flag additionally covers FFTW and libzmq. And CMAKE_AR stayed plain ar under the variable, so the archive-handling argument for it did not hold here either. Co-Authored-By: Claude Opus 5 (1M context) --- .gitea/workflows/build_and_test.yml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/.gitea/workflows/build_and_test.yml b/.gitea/workflows/build_and_test.yml index 6973cca9..6d8c5b37 100644 --- a/.gitea/workflows/build_and_test.yml +++ b/.gitea/workflows/build_and_test.yml @@ -11,6 +11,13 @@ env: # than CPU-instruction-bound. It costs about 3x on an INCREMENTAL rebuild (one file plus link, # 9.8 s -> 30.1 s), which is why it belongs here and not in CMakeLists: CI always builds from # scratch and ships the result, so it pays the link once and a developer never pays it at all. + # + # Not CMAKE_INTERPROCEDURAL_OPTIMIZATION, which is the tidier spelling and would cover MSVC too: + # built and linked fine (CUDA included, and it does not reach .cu either way), but measured 3% + # MORE retired instructions than -flto=auto - 396.9 G vs 384.9 G over three runs each against a + # 0.45% run-to-run spread, so the gap is real. It also leaves two dependencies (FFTW, libzmq) out + # of LTO that the flag reaches, and it did not switch CMAKE_AR to gcc-ar here, so the one + # correctness argument for it did not materialise either. LINUX_CMAKE_FLAGS: '-DCMAKE_CXX_FLAGS="-march=x86-64-v3 -flto=auto" -DCMAKE_C_FLAGS="-march=x86-64-v3 -flto=auto"' # MSVC has no spelling for the x86-64-v2 level; /arch:AVX is the nearest and implies SSE4.1/4.2, # which is what matters here - without it Eigen has no vectorised round and falls back to a libm