| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
The base class llvm::ThreadPoolInterface will be renamed
llvm::ThreadPool in a subsequent commit.
This is a breaking change: clients who use to create a ThreadPool must
now create a DefaultThreadPool instead.
|
|
This is addressing a long-time TODO to rename this misleading API. The
old one is preserved for now but marked deprecated.
|
|
Make core BOLT functionality more friendly to being used as a
library instead of in our standalone driver llvm-bolt. To
accomplish this, we augment BinaryContext with journaling streams
that are to be used by most BOLT code whenever something needs to
be logged to the screen. Users of the library can decide if logs
should be printed to a file, no file or to the screen, as
before. To illustrate this, this patch adds a new option
`--log-file` that allows the user to redirect BOLT logging to a
file on disk or completely hide it by using
`--log-file=/dev/null`. Future BOLT code should now use
`BinaryContext::outs()` for printing important messages instead of
`llvm::outs()`. A new test log.test enforces this by verifying that
no strings are print to screen once the `--log-file` option is
used.
In previous patches we also added a new BOLTError class to report
common and fatal errors, so code shouldn't call exit(1) now. To
easily handle problems as before (by quitting with exit(1)),
callers can now use
`BinaryContext::logBOLTErrorsAndQuitOnFatal(Error)` whenever code
needs to deal with BOLT errors. To test this, we have fatal.s
that checks we are correctly quitting and printing a fatal error
to the screen.
Because this is a significant change by itself, not all code was
yet ported. Code from Profiler libs (DataAggregator and friends)
still print errors directly to screen.
Co-authored-by: Rafael Auler <rafaelauler@fb.com>
Test Plan: NFC
|
|
Fix the bug where merge-fdata unconditionally outputs boltedcollection
line, regardless of whether input files have it set.
Test Plan:
Added bolt/test/X86/merge-fdata-nobat-mode.test which fails without this
fix.
|
|
(#78653)"
This reverts commit 82bc33ea3f1a539be50ed46919dc53fc6b685da9.
Accidentally pushed unrelated changes.
|
|
Fix the bug where merge-fdata unconditionally outputs boltedcollection
line, regardless of whether input files have it set.
Test Plan:
Added bolt/test/X86/merge-fdata-nobat-mode.test which fails without this
fix.
|
|
|
|
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
|
|
The existing BOLT install targets are broken on Windows becase they
don't properly handle the output extension. We cannot use the existing
LLVM macros since those make assumptions that don't hold for BOLT. This
change instead implements custom macros following the approach used by
Clang and LLD.
Differential Revision: https://reviews.llvm.org/D151595
|
|
This reverts commit f99a7d3e38095cfdaf7e729289a8894dd31c7efa since it
broke the bolt-aarch64-ubuntu-clang-shared bot.
|
|
The existing BOLT install targets are broken on Windows becase they
don't properly handle the output extension. We cannot use the existing
LLVM macros since those make assumptions that don't hold for BOLT. This
change instead implements custom macros following the approach used by
Clang and LLD.
Differential Revision: https://reviews.llvm.org/D151595
|
|
This reverts commit 627d5e16127bd8034b893e66ab0c86eacf2d939a.
|
|
The existing BOLT install targets are broken on Windows becase they
don't properly handle output extension. Rather than reimplementing
this logic in BOLT, reuse the existing LLVM macros which already
handle this aspect correctly.
Differential Revision: https://reviews.llvm.org/D151595
|
|
Resovled the issue that when number of tasks is fewer than cores, we end
up creating as many threads as the number of cores, making the
performance worse than the single thread version.
|
|
This reverts commit 611fb179b19857ffb87df81c926902fc7e3412ab.
Broken tests
|
|
This reverts commit 78d8d016490909ac759c6f76c5f8679bc7a58b2e.
|
|
This reverts commit 35af20d9e036deeed250b73fd3ae86d6455173c5.
The patch caused a test failure.
|
|
Merging profiles is quite expensive, but easily paralleizable.
8359 profiles on n2d-standard-128:
single-thread: 808s
multi-thread: 200s (~75% speed up)
Differential Revision: https://reviews.llvm.org/D149014
|
|
Use std::optional instead of tracking if it is the first profile seen.
Differential Revision: https://reviews.llvm.org/D147308
|
|
Follow the code style of fallible constructors in [LLVM Programmer's Manual]
(https://llvm.org/docs/ProgrammersManual.html#fallible-constructors)
and rename `RewriteInstance::createRewriteInstance` to `RewriteInstance::create`
Reviewed By: #bolt, rafauler
Differential Revision: https://reviews.llvm.org/D143119
|
|
Reviewed By: #bolt, rafauler
Differential Revision: https://reviews.llvm.org/D143019
|
|
This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.
Differential Revision: https://reviews.llvm.org/D141298
|
|
Build and install `merge-fdata` tool as part of `bolt` component:
```
$ ninja bolt
# builds llvm-bolt, perf2bolt and merge-fdata
$ cmake --install . --component bolt --prefix $HOME/test-install-bolt
-- Install configuration: "Release"
-- Install configuration: "Release"
-- Installing: /home/aaupov/test-install-bolt/lib/libbolt_rt_instr.a
-- Installing: /home/aaupov/test-install-bolt/lib/libbolt_rt_hugify.a
-- Installing: /home/aaupov/test-install-bolt/lib/libbolt_rt_instr_osx.a
-- Installing: /home/aaupov/test-install-bolt/bin/llvm-bolt
-- Installing: /home/aaupov/test-install-bolt/bin/perf2bolt
-- Installing: /home/aaupov/test-install-bolt/bin/llvm-boltdiff
-- Installing: /home/aaupov/test-install-bolt/bin/merge-fdata
```
Fixes #57249.
Reviewed By: #bolt, rafauler
Differential Revision: https://reviews.llvm.org/D139972
|
|
This does *not* link with libLLVM, but with static archives instead. Not
super-great, but at least the build works, which is probably better than
failing.
Related to #57551
Differential Revision: https://reviews.llvm.org/D134434
|
|
Non-LLVM components should not be listed as part of LLVM_LINK_COMPONENTS.
Differential Revision: https://reviews.llvm.org/D134278
|
|
This reverts commit 34ad83d883cc4505412a7c3e1e3da74e5408aa82.
|
|
Non-LLVM component should not be listed as part of LLVM_LINK_COMPONENTS
Differential Revision: https://reviews.llvm.org/D134278
|
|
Prefer using these accessors to access the special sub-commands
corresponding to the top-level (no subcommand) and all sub-commands.
This is a preparatory step towards removing the use of ManagedStatic:
with a subsequent change, these global instances will be moved to
be regular function-scope statics.
It is split up to give downstream projects a (albeit short) window in
which they can switch to using the accessors in a forward-compatible
way.
Differential Revision: https://reviews.llvm.org/D129118
|
|
This patch refactors BAT to be testable as a library, so we
can have open-source tests on it. This further fixes an issue with
basic blocks that lack a valid input offset, making BAT omit those
when writing translation tables.
Test Plan: new testcases added, new testing tool added (llvm-bat-dump)
Differential Revision: https://reviews.llvm.org/D129382
|
|
First of all, `LLVM_TOOLS_INSTALL_DIR` put there breaks our NixOS
builds, because `LLVM_TOOLS_INSTALL_DIR` defined the same as
`CMAKE_INSTALL_BINDIR` becomes an *absolute* path, and then when
downstream projects try to install there too this breaks because our
builds always install to fresh directories for isolation's sake.
Second of all, note that `LLVM_TOOLS_INSTALL_DIR` stands out against the
other specially crafted `LLVM_CONFIG_*` variables substituted in
`llvm/cmake/modules/LLVMConfig.cmake.in`.
@beanz added it in d0e1c2a550ef348aae036d0fe78cab6f038c420c to fix a
dangling reference in `AddLLVM`, but I am suspicious of how this
variable doesn't follow the pattern.
Those other ones are carefully made to be build-time vs install-time
variables depending on which `LLVMConfig.cmake` is being generated, are
carefully made relative as appropriate, etc. etc. For my NixOS use-case
they are also fine because they are never used as downstream install
variables, only for reading not writing.
To avoid the problems I face, and restore symmetry, I deleted the
exported and arranged to have many `${project}_TOOLS_INSTALL_DIR`s.
`AddLLVM` now instead expects each project to define its own, and they
do so based on `CMAKE_INSTALL_BINDIR`. `LLVMConfig` still exports
`LLVM_TOOLS_BINARY_DIR` which is the location for the tools defined in
the usual way, matching the other remaining exported variables.
For the `AddLLVM` changes, I tried to copy the existing pattern of
internal vs non-internal or for LLVM vs for downstream function/macro
names, but it would good to confirm I did that correctly.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D117977
|
|
Replace `std::` algorithms taking begin/end iterators with `llvm::` counterparts
accepting ranges.
Reviewed By: rafauler
Differential Revision: https://reviews.llvm.org/D128154
|
|
This reverts commit d5daa5c5b091cafb9b7ffd19b5dfa2daadef3229.
|
|
First of all, `LLVM_TOOLS_INSTALL_DIR` put there breaks our NixOS
builds, because `LLVM_TOOLS_INSTALL_DIR` defined the same as
`CMAKE_INSTALL_BINDIR` becomes an *absolute* path, and then when
downstream projects try to install there too this breaks because our
builds always install to fresh directories for isolation's sake.
Second of all, note that `LLVM_TOOLS_INSTALL_DIR` stands out against the
other specially crafted `LLVM_CONFIG_*` variables substituted in
`llvm/cmake/modules/LLVMConfig.cmake.in`.
@beanz added it in d0e1c2a550ef348aae036d0fe78cab6f038c420c to fix a
dangling reference in `AddLLVM`, but I am suspicious of how this
variable doesn't follow the pattern.
Those other ones are carefully made to be build-time vs install-time
variables depending on which `LLVMConfig.cmake` is being generated, are
carefully made relative as appropriate, etc. etc. For my NixOS use-case
they are also fine because they are never used as downstream install
variables, only for reading not writing.
To avoid the problems I face, and restore symmetry, I deleted the
exported and arranged to have many `${project}_TOOLS_INSTALL_DIR`s.
`AddLLVM` now instead expects each project to define its own, and they
do so based on `CMAKE_INSTALL_BINDIR`. `LLVMConfig` still exports
`LLVM_TOOLS_BINARY_DIR` which is the location for the tools defined in
the usual way, matching the other remaining exported variables.
For the `AddLLVM` changes, I tried to copy the existing pattern of
internal vs non-internal or for LLVM vs for downstream function/macro
names, but it would good to confirm I did that correctly.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D117977
|
|
Differential Revision: https://reviews.llvm.org/D126788
|
|
and recursively merge all files under said directory. This is similar
to `llvm-profdata merge`.
Differential Revision: https://reviews.llvm.org/D126695
|
|
This is the recommended way, should make merging profiles ever so
slightly faster.
|
|
When a profile is collected in a BOLTed binary, the generated
profile is tagged with a header string "boltedcollection" in the first
line of the fdata file. Fix merge-fdata to recognize this header
string and preserve it into the output.
Reviewed By: Amir
Differential Revision: https://reviews.llvm.org/D125591
|
|
Move BOLT libraries out of `LLVM_LINK_COMPONENTS` to `target_link_libraries`.
Addresses issue #55432.
Reviewed By: rafauler
Differential Revision: https://reviews.llvm.org/D125568
|
|
Add X86/AArch64 targets to resolve missing dependencies, e.g.:
`undefined reference to `LLVMInitializeX86AsmParser'`
Follow-up to D124206
Reviewed By: rafauler
Differential Revision: https://reviews.llvm.org/D124886
|
|
Merging multiple legacy profiles (produced by instrumentation BOLT) can
easily reach GiBs. Let merge-fdata compact the profiles during merge to
significantly reduce space usage.
Differential Revision: https://reviews.llvm.org/D123513
|
|
Remove `TYPE BIN` parameter that is introduced in CMake 3.14 and revert back to
the equivalent compatible form `DESTINATION ${CMAKE_INSTALL_BINDIR}`.
Addresses https://github.com/llvm/llvm-project/issues/54099
Reviewed By: rafauler
Differential Revision: https://reviews.llvm.org/D121012
|
|
Further improve error handling in BOLT by reporting `RewriteInstance` errors in
a library and fuzzer-friendly way instead of exiting.
Follow-up to D119658
Reviewed By: rafauler
Differential Revision: https://reviews.llvm.org/D120224
|
|
This adds a target that would consume random binary as an
input ELF file.
TBD: add structured input support (ELF).
Build:
```
cmake /path/to/llvm-project/llvm -GNinja \
-DLLVM_TARGETS_TO_BUILD="X86;AArch64" \
-DCMAKE_BUILD_TYPE=Release \
-DLLVM_ENABLE_ASSERTIONS=1 \
-DCMAKE_C_COMPILER=<sanitizer-capable clang> \
-DCMAKE_CXX_COMPILER=<sanitizer-capable clang++> \
-DLLVM_ENABLE_PROJECTS="bolt" \
-DLLVM_USE_SANITIZER=Address \
-DLLVM_USE_SANITIZE_COVERAGE=On
ninja llvm-bolt-fuzzer
```
Test Plan: ninja llvm-bolt-fuzzer
Reviewed By: maksfb
Differential Revision: https://reviews.llvm.org/D120016
|
|
Refactor createBinaryContext and RewriteInstance/MachORewriteInstance
constructors to report an error in a library and fuzzer-friendly way instead of
returning a nullptr or exiting.
Reviewed By: rafauler
Differential Revision: https://reviews.llvm.org/D119658
|
|
As usual with that header cleanup series, some implicit dependencies now need to
be explicit:
llvm/DebugInfo/DWARF/DWARFContext.h no longer includes:
- "llvm/DebugInfo/DWARF/DWARFAcceleratorTable.h"
- "llvm/DebugInfo/DWARF/DWARFCompileUnit.h"
- "llvm/DebugInfo/DWARF/DWARFDebugAbbrev.h"
- "llvm/DebugInfo/DWARF/DWARFDebugAranges.h"
- "llvm/DebugInfo/DWARF/DWARFDebugFrame.h"
- "llvm/DebugInfo/DWARF/DWARFDebugLoc.h"
- "llvm/DebugInfo/DWARF/DWARFDebugMacro.h"
- "llvm/DebugInfo/DWARF/DWARFGdbIndex.h"
- "llvm/DebugInfo/DWARF/DWARFSection.h"
- "llvm/DebugInfo/DWARF/DWARFTypeUnit.h"
- "llvm/DebugInfo/DWARF/DWARFUnitIndex.h"
Plus llvm/Support/Errc.h not included by a bunch of llvm/DebugInfo/DWARF/DWARF*.h files
Preprocessed lines to build llvm on my setup:
after: 1065629059
before: 1066621848
Which is a great diff!
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D119723
|
|
Separate heatmap from bolt and build it as standalone tool.
Reviewed By: maksfb
Differential Revision: https://reviews.llvm.org/D118946
|
|
emit-relocs option
Only enable --emit-relocs linker option for merge-fdata target if tests are enabled.
Reviewed By: maksfb
Differential Revision: https://reviews.llvm.org/D118580
|
|
This patch adds unit testing support for BOLT. In order to do this we will need at least do this changes on the code level:
* Make createMCPlusBuilder accessible externally
* Remove positional InputFilename argument to bolt utlity sources
And prepare the cmake and lit for the new tests.
Vladislav Khmelevsky,
Advanced Software Technology Lab, Huawei
Reviewed By: maksfb, Amir
Differential Revision: https://reviews.llvm.org/D118271
|
|
Summary:
Refactor remaining bolt sources to follow the braces rule for if/else/loop from
[LLVM Coding Standards](https://llvm.org/docs/CodingStandards.html).
(cherry picked from FBD33345885)
|
