|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
| #
8477bc67 |
| 17-Jul-2022 |
Fabian Parzefall <[email protected]> |
[BOLT] Add function layout class
This patch adds a dedicated class to keep track of each function's layout. It also lays the groundwork for splitting functions into multiple fragments (as opposed to
[BOLT] Add function layout class
This patch adds a dedicated class to keep track of each function's layout. It also lays the groundwork for splitting functions into multiple fragments (as opposed to a strict hot/cold split).
Reviewed By: maksfb
Differential Revision: https://reviews.llvm.org/D129518
show more ...
|
| #
d2c87699 |
| 24-Jun-2022 |
Amir Ayupov <[email protected]> |
[BOLT][NFC] Use range-based STL wrappers
Replace `std::` algorithms taking begin/end iterators with `llvm::` counterparts accepting ranges.
Reviewed By: rafauler
Differential Revision: https://rev
[BOLT][NFC] Use range-based STL wrappers
Replace `std::` algorithms taking begin/end iterators with `llvm::` counterparts accepting ranges.
Reviewed By: rafauler
Differential Revision: https://reviews.llvm.org/D128154
show more ...
|
|
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4 |
|
| #
253b8f0a |
| 13-May-2022 |
Amir Ayupov <[email protected]> |
[BOLT][NFC] Use refs for loop variables to avoid copies
Addresses warnings when built with Apple Clang.
Reviewed By: yota9
Differential Revision: https://reviews.llvm.org/D125483
|
| #
625e0e61 |
| 03-May-2022 |
Paul Kirth <[email protected]> |
[BOLT] [NFC] Remove unused variable
This patch fixes a warning from -Wunused-but-set-variable MismatchedBranches are counted, but are never reported. Since evaluateProfileData() should already ident
[BOLT] [NFC] Remove unused variable
This patch fixes a warning from -Wunused-but-set-variable MismatchedBranches are counted, but are never reported. Since evaluateProfileData() should already identify and report these cases, we can safely remove the unused variable.
Reviewed By: rafauler
Differential Revision: https://reviews.llvm.org/D124588
show more ...
|
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2 |
|
| #
76981fbc |
| 20-Apr-2022 |
Maksim Panchenko <[email protected]> |
[BOLT] Add fuzzy function name matching for LLVM LTO
LLVM with LTO can generate function names in the form func.llvm.<number>, where <number> could vary based on the compilation environment. As a re
[BOLT] Add fuzzy function name matching for LLVM LTO
LLVM with LTO can generate function names in the form func.llvm.<number>, where <number> could vary based on the compilation environment. As a result, if a profiled binary originated from a different build than a corresponding binary used for BOLT optimization, then profiles for such LTO functions will be ignored.
To fix the problem, use "fuzzy" matching with "func.llvm.*" form.
Reviewed By: yota9, Amir
Differential Revision: https://reviews.llvm.org/D124117
show more ...
|
|
Revision tags: llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2 |
|
| #
290e4823 |
| 14-Feb-2022 |
serge-sans-paille <[email protected]> |
Cleanup LLVMDWARFDebugInfo
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/DW
Cleanup LLVMDWARFDebugInfo
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
show more ...
|
|
Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2 |
|
| #
a9cd49d5 |
| 04-Aug-2021 |
Amir Ayupov <[email protected]> |
[BOLT][NFC] Move Offset annotation to Group 1
Summary: Move the annotation to avoid dynamic memory allocations. Improves the CPU time of instrumenting a large binary by 1% (+-0.8%, p-value 0.01)
Te
[BOLT][NFC] Move Offset annotation to Group 1
Summary: Move the annotation to avoid dynamic memory allocations. Improves the CPU time of instrumenting a large binary by 1% (+-0.8%, p-value 0.01)
Test Plan: NFC
Reviewers: maksfb
FBD30091656
show more ...
|
| #
def464aa |
| 29-Dec-2021 |
Amir Ayupov <[email protected]> |
[BOLT][NFC] Fix braces usage in Profile
Summary: Refactor bolt/*/Profile to follow the braces rule for if/else/loop from [LLVM Coding Standards](https://llvm.org/docs/CodingStandards.html).
(cherry
[BOLT][NFC] Fix braces usage in Profile
Summary: Refactor bolt/*/Profile to follow the braces rule for if/else/loop from [LLVM Coding Standards](https://llvm.org/docs/CodingStandards.html).
(cherry picked from FBD33345741)
show more ...
|
| #
2f09f445 |
| 21-Dec-2021 |
Maksim Panchenko <[email protected]> |
[BOLT][NFC] Fix file-description comments
Summary: Fix comments at the start of source files.
(cherry picked from FBD33274597)
|
| #
226c9732 |
| 02-Dec-2021 |
Maksim Panchenko <[email protected]> |
[BOLT][NFC] Remove another unused function
Summary: Remove DataReader::getBranchRange().
(cherry picked from FBD32810933)
|
| #
ccb99dd1 |
| 19-Dec-2021 |
Maksim Panchenko <[email protected]> |
[BOLT] Fix profile and tests for nop-removal pass
Summary: Since nops are now removed in a separate pass, the profile is consumed on a CFG with nops. If previously a profile was generated without no
[BOLT] Fix profile and tests for nop-removal pass
Summary: Since nops are now removed in a separate pass, the profile is consumed on a CFG with nops. If previously a profile was generated without nops, the offsets in the profile could be different if branches included nops either as a source or a destination.
This diff adjust offsets to make the profile reading backwards compatible.
(cherry picked from FBD33231254)
show more ...
|
| #
08f56926 |
| 19-Dec-2021 |
Vladislav Khmelevsky <[email protected]> |
[BOLT] Move disassemble optimizations to optimization passes
Summary: The patch moves the shortenInstructions and nop remove to separate binary passes. As a result when llvm-bolt optimizations stage
[BOLT] Move disassemble optimizations to optimization passes
Summary: The patch moves the shortenInstructions and nop remove to separate binary passes. As a result when llvm-bolt optimizations stage will begin the instructions of the binary functions will be absolutely the same as it was in the binary. This is needed for the golang support by llvm-bolt. Some of the tests must be changed, since bb alignment nops might create unreachable BBs in original functions.
Vladislav Khmelevsky, Advanced Software Technology Lab, Huawei
(cherry picked from FBD32896517)
show more ...
|
| #
40c2e0fa |
| 15-Dec-2021 |
Maksim Panchenko <[email protected]> |
[BOLT][NFC] Reformat with clang-format
Summary: Selectively apply clang-format to BOLT code base.
(cherry picked from FBD33119052)
|
| #
a34c753f |
| 08-Oct-2021 |
Rafael Auler <[email protected]> |
Rebase: [NFC] Refactor sources to be buildable in shared mode
Summary: Moves source files into separate components, and make explicit component dependency on each other, so LLVM build system knows h
Rebase: [NFC] Refactor sources to be buildable in shared mode
Summary: Moves source files into separate components, and make explicit component dependency on each other, so LLVM build system knows how to build BOLT in BUILD_SHARED_LIBS=ON.
Please use the -c merge.renamelimit=230 git option when rebasing your work on top of this change.
To achieve this, we create a new library to hold core IR files (most classes beginning with Binary in their names), a new library to hold Utils, some command line options shared across both RewriteInstance and core IR files, a new library called Rewrite to hold most classes concerned with running top-level functions coordinating the binary rewriting process, and a new library called Profile to hold classes dealing with profile reading and writing.
To remove the dependency from BinaryContext into X86-specific classes, we do some refactoring on the BinaryContext constructor to receive a reference to the specific backend directly from RewriteInstance. Then, the dependency on X86 or AArch64-specific classes is transfered to the Rewrite library. We can't have the Core library depend on targets because targets depend on Core (which would create a cycle).
Files implementing the entry point of a tool are transferred to the tools/ folder. All header files are transferred to the include/ folder. The src/ folder was renamed to lib/.
(cherry picked from FBD32746834)
show more ...
|