[CMake] Add clang-bolt target

[Amir]

Summary

This patch adds CLANG_BOLT_INSTRUMENT option that applies BOLT instrumentation
to Clang, performs a bootstrap build with the resulting Clang, merges resulting
fdata files into a single profile file, and uses it to perform BOLT optimization
on the original Clang binary.

The projects and targets used for bootstrap/profile collection are configurable via
CLANG_BOLT_INSTRUMENT_PROJECTS and CLANG_BOLT_INSTRUMENT_TARGETS.
The defaults are "llvm" and "count" respectively, which results in a profile with
~5.3B dynamically executed instructions.

The intended use of the functionality is through BOLT CMake cache file, similar
to PGO 2-stage build:

cmake <llvm-project>/llvm -C <llvm-project>/clang/cmake/caches/BOLT.cmake
ninja clang++-bolt # pulls clang-bolt

Stats with a recent checkout (clang-16), pre-built BOLT and Clang, 72vCPU/224G

CMake configure with host Clang + BOLT.cmake	1m6.592s
Instrumenting Clang with BOLT	2m50.508s
CMake configure llvm with instrumented Clang	5m46.364s (~5x slowdown)
CMake build not with instrumented Clang	0m6.456s
Merging fdata files	0m9.439s
Optimizing Clang with BOLT	0m39.201s

Building Clang:

cmake ../llvm-project/llvm -DCMAKE_C_COMPILER=... -DCMAKE_CXX_COMPILER=...
  -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=clang 
  -DLLVM_TARGETS_TO_BUILD=Native -GNinja

	Release	BOLT-optimized
cmake	0m24.016s	0m22.333s
ninja clang	5m55.692s	4m35.122s

I know it's not rigorous, but shows a ballpark figure.

[Amir]

CMAKE_CURRENT_BINARY_DIR already contains bin/

[Amir]

Succeeded instrumenting Clang with BOLT

[Amir]

Successfully invoke the bootstrap/profiling build

[phosek]

This was already on my list of build system features I'd like to implement and I'm glad someone else is already looking into it, thank you! I have two high level comments about your approach.

The first one is related to the use of Clang build as the training data. I think that Clang build is both unnecessarily heavyweight, but also not particularly representative of typical workloads (most Clang users don't use it to build Clang). Ideally, we would give vendors the flexibility to supply their own training data. I'd prefer reusing the existing perf-training setup to do so. In fact, I'd imagine most vendors would likely use the same training data for both PGO and BOLT and that use case should be supported.

The second one is related to applicability. I don't think this mechanism should be limited only to Clang. Ideally, it should be possible to instrument and optimize other tools in the toolchain distribution as well; LLD is likely going to be the most common one after Clang.

[Amir]

Succeeded in producing optimized Clang. Switch the default profiling target
from lld to count, which produces a sufficient Clang coverage of 5.3B exec
insns (along with configure-stage Clang invocations).

[Amir]

Hi Petr, thank you for your comments!

In D132975#3763264, @phosek wrote:

This was already on my list of build system features I'd like to implement and I'm glad someone else is already looking into it, thank you! I have two high level comments about your approach.

The first one is related to the use of Clang build as the training data. I think that Clang build is both unnecessarily heavyweight, but also not particularly representative of typical workloads (most Clang users don't use it to build Clang). Ideally, we would give vendors the flexibility to supply their own training data. I'd prefer reusing the existing perf-training setup to do so. In fact, I'd imagine most vendors would likely use the same training data for both PGO and BOLT and that use case should be supported.

Agree that perf-training might be useful for vendors. I'll try to enable it in a follow-up diff.

Please note that the target for profile collection is not hardcoded to clang, it's configurable via CLANG_BOLT_INSTRUMENT_PROJECTS and CLANG_BOLT_INSTRUMENT_TARGETS. Right now it's the llvm/not tool (the smallest possible).

The second one is related to applicability. I don't think this mechanism should be limited only to Clang. Ideally, it should be possible to instrument and optimize other tools in the toolchain distribution as well; LLD is likely going to be the most common one after Clang.

I thought about it, and I think we can accommodate optimizing arbitrary targets by providing an interface to instrument specified target(s) via -DBOLT_INSTRUMENT_TARGETS. For each of the target binaries, CMake would create targets like bolt-instrument-$TARGET and bolt-optimize-$TARGET.
For bolt-instrument-$TARGET, BOLT would instrument the target binary, placing instrumented binary next to the original one (e.g. $target-bolt.inst). End users would use those instrumented binaries on representative workloads to collect the profile. For bolt-optimize-$TARGET, BOLT would post-process the profiles and create optimized binary ($target-bolt).

I appreciate your suggestions. Do you think we can move incrementally from this diff towards more general uses in follow-up diffs?

[Amir]

Fix up paths

[phosek]

In D132975#3765541, @Amir wrote:

Hi Petr, thank you for your comments!

In D132975#3763264, @phosek wrote:

This was already on my list of build system features I'd like to implement and I'm glad someone else is already looking into it, thank you! I have two high level comments about your approach.

The first one is related to the use of Clang build as the training data. I think that Clang build is both unnecessarily heavyweight, but also not particularly representative of typical workloads (most Clang users don't use it to build Clang). Ideally, we would give vendors the flexibility to supply their own training data. I'd prefer reusing the existing perf-training setup to do so. In fact, I'd imagine most vendors would likely use the same training data for both PGO and BOLT and that use case should be supported.

Agree that perf-training might be useful for vendors. I'll try to enable it in a follow-up diff.

Please note that the target for profile collection is not hardcoded to clang, it's configurable via CLANG_BOLT_INSTRUMENT_PROJECTS and CLANG_BOLT_INSTRUMENT_TARGETS. Right now it's the llvm/not tool (the smallest possible).

The second one is related to applicability. I don't think this mechanism should be limited only to Clang. Ideally, it should be possible to instrument and optimize other tools in the toolchain distribution as well; LLD is likely going to be the most common one after Clang.

I thought about it, and I think we can accommodate optimizing arbitrary targets by providing an interface to instrument specified target(s) via -DBOLT_INSTRUMENT_TARGETS. For each of the target binaries, CMake would create targets like bolt-instrument-$TARGET and bolt-optimize-$TARGET.
For bolt-instrument-$TARGET, BOLT would instrument the target binary, placing instrumented binary next to the original one (e.g. $target-bolt.inst). End users would use those instrumented binaries on representative workloads to collect the profile. For bolt-optimize-$TARGET, BOLT would post-process the profiles and create optimized binary ($target-bolt).

I appreciate your suggestions. Do you think we can move incrementally from this diff towards more general uses in follow-up diffs?

That's fine with me. Do you envision replacing the use of LLVM build for training with perf-training or supporting both? I'd lean towards the former for simplicity but would be curious to hear about your use cases and plans.

clang/CMakeLists.txt

881

We could consider moving this block to a separate file which would then be included here since this file is already getting pretty large and the logic in this block is self-contained. That could be done in a follow up change though.

955

I'd like to avoid dependency on shell to make this compatible with Windows. Can we move this logic into a Python script akin to https://github.com/llvm/llvm-project/blob/607f14d9605da801034e7119c297c3f58ebce603/clang/utils/perf-training/perf-helper.py?

[phosek]

clang/CMakeLists.txt

930–937

I don't think this is sufficient in the general case, we would need to pass additional variables like CMAKE_AR the same way we do for the existing bootstrap logic, see https://github.com/llvm/llvm-project/blob/dc549bf0013e11e8fcccba8a8d59c3a4bb052a3b/clang/CMakeLists.txt#L825.

For example, on Fuchsia builders we don't have any system-wide toolchain installation, instead we manually set all necessary CMAKE_<TOOL> variables for the first stage, so this call will fail for us because it won't be able to find tools like the archiver.

Since handling this properly would likely duplicate a lot of the existing logic from the existing bootstrap logic, I'm wondering if we should instead try to refactor the existing logic and break it up into macros/functions which could then be reused here as well.

[tschuett]

Will there be eventually a way to build a fully optimised clang/lld with ThinLTO, PGO, and Bolt?

[Amir]

In D132975#3768391, @tschuett wrote:

Will there be eventually a way to build a fully optimised clang/lld with ThinLTO, PGO, and Bolt?

Short answer is likely yes.
For clang, I think this diff should be compatible with PGO, with a caveat that BOLT should be applied to stage-2 clang built with PGO, which means that BOOTSTRAP_ options should be set carefully. And for sure it's compatible with ThinLTO - this one is completely orthogonal.
For lld, I can envision a similar fully automated optimized build, but likely in a future separate diff.

[MaskRay]

clang/CMakeLists.txt

930–937

Supporting other cmake variables will be awesome. I use something like -DCMAKE_CXX_ARCHIVE_CREATE="$HOME/llvm/out/stable/bin/llvm-ar qcS --thin <TARGET> <OBJECTS>" -DCMAKE_CXX_ARCHIVE_FINISH=: to make my build smaller.

[Amir]

Address @phosek's comment about dependency on shell

[Amir]

clang/CMakeLists.txt

930–937

Addressed in D133633

[Amir]

Add an ability to pass extra cmake flags

[Amir]

clang/CMakeLists.txt

930–937

Done: -DCLANG_BOLT_INSTRUMENT_EXTRA_CMAKE_FLAGS is passed to the cmake step of bolt-instrumentation-profile target.
I tested it with

-DCLANG_BOLT_INSTRUMENT_EXTRA_CMAKE_FLAGS='-DCMAKE_CXX_ARCHIVE_CREATE="<path/to/llvm/bin>/llvm-ar qcS --thin <TARGET> <OBJECTS>" -DCMAKE_CXX_ARCHIVE_FINISH=:'

and that appeared to work.

[phosek]

LGTM

[Amir]

In D132975#3763264, @phosek wrote:

This was already on my list of build system features I'd like to implement and I'm glad someone else is already looking into it, thank you! I have two high level comments about your approach.

The first one is related to the use of Clang build as the training data. I think that Clang build is both unnecessarily heavyweight, but also not particularly representative of typical workloads (most Clang users don't use it to build Clang). Ideally, we would give vendors the flexibility to supply their own training data. I'd prefer reusing the existing perf-training setup to do so. In fact, I'd imagine most vendors would likely use the same training data for both PGO and BOLT and that use case should be supported.

Do you happen to know any existing perf-training sets? Or is there a simple way to create one?

[phosek]

In D132975#3860896, @Amir wrote:

In D132975#3763264, @phosek wrote:

This was already on my list of build system features I'd like to implement and I'm glad someone else is already looking into it, thank you! I have two high level comments about your approach.

The first one is related to the use of Clang build as the training data. I think that Clang build is both unnecessarily heavyweight, but also not particularly representative of typical workloads (most Clang users don't use it to build Clang). Ideally, we would give vendors the flexibility to supply their own training data. I'd prefer reusing the existing perf-training setup to do so. In fact, I'd imagine most vendors would likely use the same training data for both PGO and BOLT and that use case should be supported.

Do you happen to know any existing perf-training sets? Or is there a simple way to create one?

I'm working on a script for generating perf-training sets from Ninja-based build systems, I can contribute it to LLVM if you think it'd be useful.

[Amir]

In D132975#3861334, @phosek wrote:

In D132975#3860896, @Amir wrote:

In D132975#3763264, @phosek wrote:

This was already on my list of build system features I'd like to implement and I'm glad someone else is already looking into it, thank you! I have two high level comments about your approach.

The first one is related to the use of Clang build as the training data. I think that Clang build is both unnecessarily heavyweight, but also not particularly representative of typical workloads (most Clang users don't use it to build Clang). Ideally, we would give vendors the flexibility to supply their own training data. I'd prefer reusing the existing perf-training setup to do so. In fact, I'd imagine most vendors would likely use the same training data for both PGO and BOLT and that use case should be supported.

Do you happen to know any existing perf-training sets? Or is there a simple way to create one?

I'm working on a script for generating perf-training sets from Ninja-based build systems, I can contribute it to LLVM if you think it'd be useful.

Yes, that would be super useful. BOLT should then also leverage that.

clang/CMakeLists.txt

foreach(target ${CLANG_BOOTSTRAP_TARGETS})
     if(target MATCHES "^stage[0-9]*")
       add_custom_target(${target} DEPENDS ${NEXT_CLANG_STAGE}-${target})
     endif()
 
     ExternalProject_Add_StepTargets(${NEXT_CLANG_STAGE} ${target})
   endforeach()
 endif()
 
+if (CLANG_BOLT_INSTRUMENT)
+  find_program(LLVM_BOLT llvm-bolt)
+  find_program(MERGE_FDATA merge-fdata)
+
+  # Instrument clang with BOLT
+  add_custom_target(clang-instrumented
+    DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/clang.bolt.inst
+  )
+  add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/clang.bolt.inst
+    DEPENDS clang
+    COMMAND ${LLVM_BOLT} ${CMAKE_BINARY_DIR}/clang -o
+      ${CMAKE_CURRENT_BINARY_DIR}/clang.bolt.inst
+      -instrument --instrumentation-file-append-pid
+      --instrumentation-file=${CMAKE_CURRENT_BINARY_DIR}/prof.fdata
+    COMMENT "Instrumenting clang binary with BOLT"
+    )
+  # Make a symlink from clang.bolt.inst to clang++.bolt.inst
+  add_clang_symlink(${CMAKE_CURRENT_BINARY_DIR}/clang++.bolt.inst
+                    ${CMAKE_CURRENT_BINARY_DIR}/clang.bolt.inst)
+
+  # Configure and build Clang with instrumented Clang to collect the profile
+  include(ExternalProject)
+  ExternalProject_Add(bolt-instrumentation-profile
+    DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/clang.bolt.inst
+    PREFIX bolt-instrumentation-profile
+    SOURCE_DIR ${CMAKE_SOURCE_DIR}
+    CMAKE_ARGS
+                # We shouldn't need to set this here, but INSTALL_DIR doesn't
+                # seem to work, so instead I'm passing this through
+                -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
+                -DCMAKE_CXX_COMPILER=${CMAKE_CURRENT_BINARY_DIR}/clang++.bolt.inst
+                -DCMAKE_C_COMPILER=${CMAKE_CURRENT_BINARY_DIR}/clang.bolt.inst
+    STEP_TARGETS configure build install
+  )
+  # Merge profiles into one using merge-fdata
+  add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/prof.fdata
+    COMMAND ${MERGE_FDATA} ${CMAKE_CURRENT_BINARY_DIR}/prof.fdata.*
+      -o ${CMAKE_CURRENT_BINARY_DIR}/prof.fdata
+  )
+  # Optimize original (pre-bolt) Clang using the collected profile
+  add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/clang.bolt
+    DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/prof.fdata clang
+    COMMAND ${LLVM_BOLT} ${CMAKE_BINARY_DIR}/clang
+    -o ${CMAKE_CURRENT_BINARY_DIR}/clang.bolt -data ${CMAKE_CURRENT_BINARY_DIR}/prof.fdata
+  )
+  add_custom_target(clang-bolt
+    DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/clang.bolt
+    )
+endif()
+
 if (LLVM_ADD_NATIVE_VISUALIZERS_TO_SOLUTION)
   add_subdirectory(utils/ClangVisualizers)
 endif()
 add_subdirectory(utils/hmaptool)
 
 if(CLANG_BUILT_STANDALONE)
   llvm_distribution_add_targets()
   process_llvm_pass_plugins()
 endif()
 
 set(CLANG_INSTALL_LIBDIR_BASENAME "lib${CLANG_LIBDIR_SUFFIX}")
 
 configure_file(
   ${CLANG_SOURCE_DIR}/include/clang/Config/config.h.cmake
   ${CLANG_BINARY_DIR}/include/clang/Config/config.h)

clang/cmake/caches/BOLT.cmake

+set(CMAKE_BUILD_TYPE Release CACHE STRING "")
+set(CLANG_BOLT_INSTRUMENT ON CACHE BOOL "")
+set(CMAKE_EXE_LINKER_FLAGS "-Wl,--emit-relocs,-znow" CACHE STRING "")
+
+set(LLVM_ENABLE_PROJECTS "bolt;clang;lld" CACHE STRING "")
+set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
+
+# Disable function splitting enabled by default in GCC8+
+if("${CMAKE_CXX_COMPILER_ID}" MATCHES "GNU")
+  set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fno-reorder-blocks-and-partition")
+  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-reorder-blocks-and-partition")
+endif()