This fixes the llvm-support build that generates the profile data, and
wraps the whole `cmake --build` command with perf instead of wrapping
each individual clang invocation. This limits the number of profile
files generated and reduces the time spent running perf2bolt.
The first path argument was always being ignored, and since most calls
to this command only passed one path, it wasn't actually doing anything
in most cases.
This bug was introduced by dd0356d741aefa25ece973d6cc4b55dcb73b84b4.
This adds a build of the libLLVMSupport to the lit suite that is used
for generating profile data. This helps to improve both PGO and BOLT
optimization of clang over the existing hello world training program.
I considered building all of LLVM instead of just libLLVMSupport, but
there is only a marginal increase in performance for PGO only builds
when training with a build of all of LLVM, and I didn't think it was
enough to justify the increased build times given that it is the default
configuration.
The benchmark[1] I did showed that using libLLVMSupport for training
gives a 1.35 +- 0.02 speed up for clang optimized with PGO + BOLT vs
just 1.05 +- 0.01 speed up when training with hello world.
For comparison, training with a full LLVM build gave a speed up of 1.35
+- 0.1.
Raw data:
| PGO Training | BOLT Training | Speed Up | Error Range |
| ------------ | ------------- | -------- | ----------- |
| LLVM Support | LLVM Support | 1.35 | 0.02 |
| LLVM All | LLVM All | 1.34 | 0.01 |
| LLVM Support | Hello World | 1.29 | 0.02 |
| LLVM All | PGO-ONLY | 1.27 | 0.02 |
| LLVM Support | PGO-ONLY | 1.22 | 0.02 |
| Hello World | Hello World | 1.05 | 0.01 |
| Hello World | PGO-ONLY | 1.03 | 0.01 |
Time it takes to generate profile data (on a 64-core system):
| Training Data | PGO | BOLT |
| ------------- | ----- | ----- |
| LLVM All | 1090s | 3239s |
| LLVM Support | 91s | 655s |
| Hello World | 2s | 9s |
[1] Benchmark was compiling SemaDecl.cpp
This fixes two problems with the 2-stage PGO builds. The first problem
was that the stage2-instrumented and stage2 targets would not be built
on the second ninja invocation. For example:
This would work as expected.
$ ninja -v -C build stage2-instrumented-generate-profdata
Edit a file.
$ touch llvm/lib/Support/StringExtras.cpp
This would rebuild stage1 only and not build stage2-instrumented or
regenerate the profile data.
$ ninja -v -C build stage2-instrumented-generate-profdata
The second problem was that in some cases, the profile data would be
regenerated, but not all of the stage2 targets would be rebuilt. One
common scenario where this would happen is:
This would work as expected.
$ ninja -C build stage2-check-all
This would regenerate the profile data, but then only build the
targets that were needed for install, but weren't needed for
check-all. This would cause errors like:
ld.lld: error: Function Import: link error: linking module flags
'ProfileSummary': IDs have conflicting values in ...
This is because the executibles being built for the install target
used the new profile data, but they were linking with libraries that
used the old profile data.
$ ninja -C build stage2-install
With this change we can re-enable PGO for the release builds.
The new CLANG_PGO_TRAINING_DATA_SOURCE_DIR allows users to specify a
CMake project to use for generating the profile data. For example, to
use the llvm-test-suite to generate profile data you would do:
$ cmake -G Ninja -B build -S llvm -C <path to
source>/clang/cmake/caches/PGO.cmake \
-DBOOTSTRAP_CLANG_PGO_TRAINING_DATA_SOURCE_DIR=<path to llvm-test-suite>
\
-DBOOTSTRAP_CLANG_PGO_TRAINING_DEPS=runtimes
Note that the CLANG_PERF_TRAINING_DEPS has been renamed to
CLANG_PGO_TRAINING_DEPS.
---------
Co-authored-by: Petr Hosek <phosek@google.com>
This reverts commit 745883bba69007f1d2c5135f3d5b0f1efcfc82cd.
This is failing to configure on many of our bots:
https://lab.llvm.org/buildbot/#/builders/245/builds/19468
This did not get caught right away because generally bots only
clean the build every so often.
Split up and refactor CLANG_BOLT_INSTRUMENT into support for
BOLT instrumentation, perf no-LBR and perf with LBR profiling.
Differential Revision: https://reviews.llvm.org/D143617
This is an ongoing series of commits that are reformatting our
Python code.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: MatzeB
Differential Revision: https://reviews.llvm.org/D150761
`findFilesWithExtension` helper checks for `endswith(extension)` instead of
exactly matching the file extension. This causes it to match unrelated files,
for example, `.profdata` files while matching `.fdata` files:
http://157.230.108.44:8011/#/builders/56/builds/247
```
Merging data from /worker/worker/bolt-x86_64-ubuntu-clang-bolt-gcc/build/tools/clang/prof.fdata.1124569.fdata...
Merging data from /worker/worker/bolt-x86_64-ubuntu-clang-bolt-gcc/build/tools/clang/test/Frontend/Output/optimization-remark-with-hotness-new-pm.c.tmp.profdata...
```
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D141342
`findFilesWithExtension` helper checks for `endswith(extension)` instead of
exactly matching the file extension. This causes it to match unrelated files,
for example, `.profdata` files while matching `.fdata` files:
http://157.230.108.44:8011/#/builders/56/builds/247
```
Merging data from /worker/worker/bolt-x86_64-ubuntu-clang-bolt-gcc/build/tools/clang/prof.fdata.1124569.fdata...
Merging data from /worker/worker/bolt-x86_64-ubuntu-clang-bolt-gcc/build/tools/clang/test/Frontend/Output/optimization-remark-with-hotness-new-pm.c.tmp.profdata...
```
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D141342
It may be necessary to build additional targets before running
perf-training, the typical use case would be builtins and runtimes.
This change allows users to specify those dependencies as:
set(CLANG_PERF_TRAINING_DEPS builtins runtimes CACHE STRING "")
Differential Revision: https://reviews.llvm.org/D138974
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.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D132975
CLANG_TOOLS_DIR holds the the current bin/ directory, maybe with a %(build_mode)
placeholder. It is used to add the just-built binaries to $PATH for lit tests.
In most cases it equals LLVM_TOOLS_DIR, which is used for the same purpose.
But for a standalone build of clang, CLANG_TOOLS_DIR points at the build tree
and LLVM_TOOLS_DIR points at the provided LLVM binaries.
Currently CLANG_TOOLS_DIR is set in clang/test/, clang-tools-extra/test/, and
other things always built with clang. This is a few cryptic lines of CMake in
each place. Meanwhile LLVM_TOOLS_DIR is provided by configure_site_lit_cfg().
This patch moves CLANG_TOOLS_DIR to configure_site_lit_cfg() and renames it:
- there's nothing clang-specific about the value
- it will also replace LLD_TOOLS_DIR, LLDB_TOOLS_DIR etc (not in this patch)
It also defines CURRENT_LIBS_DIR. While I removed the last usage of
CLANG_LIBS_DIR in e4cab4e24d1, there are LLD_LIBS_DIR usages etc that
may be live, and I'd like to mechanically update them in a followup patch.
Differential Revision: https://reviews.llvm.org/D121763
This clarifies that this is an LLVM specific variable and avoids
potential conflicts with other projects.
Differential Revision: https://reviews.llvm.org/D119918
This reverts commit 35edd704e0fda09e8e634515c0b451d4a8b6b914.
Revert the revert and extend the patch further to account for the use of
the `PYTHONINTERP_FOUND`.
This is primarily motivated by the desire to move from Python2 to
Python3. `PYTHON_EXECUTABLE` is ambiguous. This explicitly identifies
the python interpreter in use. Since the LLVM build seems to be able to
completed successfully with python3, use that across the build. The old
path aliases `PYTHON_EXECUTABLE` to be treated as Python3.
This reverts commit cd84bfb8142bc7ff3a07a188ffb809f1d86d1fd7. Although
this passed the CI in phabricator, some of the bots are missing python3
packages, revert it temporarily.
This is primarily motivated by the desire to move from Python2 to
Python3. `PYTHON_EXECUTABLE` is ambiguous. This explicitly identifies
the python interpreter in use. Since the LLVM build seems to be able to
completed successfully with python3, use that across the build. The old
path aliases `PYTHON_EXECUTABLE` to be treated as Python3.
EXCLUDE_FROM_ALL means something else for add_lit_testsuite as it does
for something like add_executable. Distinguish between the two by
renaming the variable and making it an argument to add_lit_testsuite.
Differential revision: https://reviews.llvm.org/D74168
Summary: With %p, each test file that we're using to generate profile data will make its own profraw file which is around 60 MB in size. If we have a lot of test files, that quickly uses a lot of space. Use %4m instead to share the profraw files used to store the profile data. We use 4 here based on the default value in https://reviews.llvm.org/source/llvm-github/browse/master/llvm/CMakeLists.txt$604
Reviewers: beanz, phosek, xiaobai, smeenai, vsk
Reviewed By: vsk
Subscribers: vsk, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D71585
We may wish to keep the PGO training data outside the repository. Add a
CMake variable to allow referencing an external lit testsuite.
Differential Revision: https://reviews.llvm.org/D71507
This reverts commit 9178b10163f758cbf8a5290ea6a827990427ddc0 (r365969).
We are back to using Python2 and this is failing. This should instead be made
to be compatible with both Python 2 and 3.
llvm-svn: 366953
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Current clang fail to bootstrap in PGO mode when only python3 is available,
because perf-helper.py is not compatible with python3.
Commited on behalf of Romain Geissler.
Differential Revision: https://reviews.llvm.org/D54071
llvm-svn: 350955
In Python3, dict.items, dict.keys, dict.values, zip, map and filter no longer return lists, they create generator instead.
The portability patch consists in forcing an extra `list` call if the result is actually used as a list.
`map` are replaced by list comprehension and `filter` by filtered list comprehension.
Differential Revision: https://reviews.llvm.org/D55197
llvm-svn: 349501
At the moment if LLVM_BUILD_INSTRUMENTED is set to True
one has to set LLVM_PROFTDATA even if it's not really used
(because of message(FATAL_ERROR ...)).
Building the instrumented version of Clang can be useful even if
one doesn't plan to build the target generate-profdata
(currently that target would only compile utils/perf-training/cxx/hello_world.cpp).
For example, one can run the instrumented version of Clang
via a separate build system against a different codebase,
collect/analyze the profiles and merge them by llvm-profdata later.
Differential revision: https://reviews.llvm.org/D38859
llvm-svn: 315665
This diff replaces --driver-mode=cpp in
utils/perf-training/order-files.lit.cfg and
utils/perf-training/lit.cfg with --driver-mode=g++.
clang --driver-mode=cpp will call the preprocessor and will not
trigger compilation.
Differential revision: https://reviews.llvm.org/D28269
llvm-svn: 290936
This diff fixes the clean build of the target generate-order-file.
In llvm/tools/clang/CMakeLists.txt
add_subdirectory(utils/perf-training) should go after the block where
the value of the variable CLANG_ORDER_FILE is set - otherwise
(tested with cmake's version 3.6.2) the arguments of perf-helper.py gen-order-file
will be ill-formed (CLANG_ORDER_FILE will be empty).
Differential revision: https://reviews.llvm.org/D28153
llvm-svn: 290781
The oneshot probe only gets executed the first time the probe is hit in the process. For order file generation this is really all we care about.
llvm-svn: 279673
This reverts commit r277487.
Removing the probe predicate was a red herring. It results in more symbols being placed in the final order file, but they are symbols from outside the clang image.
llvm-svn: 277492
Having the dtrace predicate setup to only show probes in clang filters out static initializers executed by dyld, which we do want included in the order files.
llvm-svn: 277487
Dtrace probemod needs to be based on the first argument of the command, not the first argument of the args. This error was introduced a while back when I added support for skipping the driver and invoking cc1 directly.
llvm-svn: 277401
After r272599, -DLLVM_BUILD_INSTRUMENTED passes a default argument to
-fprofile-instr-generate. This confuses the perf-helper script because
the runtime emits a note stating that the default is overridden by the
LLVM_PROFILE_FILE environment variable.
Change the perf-helper script s.t it does not treat these notes as
failures.
This isn't a strictly NFC change, but I don't see a simple way to add a
test for it.
llvm-svn: 272695
