#
e7244d86 |
| 08-Jan-2025 |
Nikita Popov <npopov@redhat.com> |
[BOLT][CMake] Don't export bolt libraries in LLVMExports.cmake (#121936)
Bolt makes use of add_llvm_library and as such ends up exporting its
libraries from LLVMExports.cmake, which is not correct.
[BOLT][CMake] Don't export bolt libraries in LLVMExports.cmake (#121936)
Bolt makes use of add_llvm_library and as such ends up exporting its
libraries from LLVMExports.cmake, which is not correct.
Bolt doesn't have its own exports file, and I assume that there is no
desire to have one either -- Bolt libraries are not intended to be
consumed as a cmake module, right?
As such, this PR adds a NO_EXPORT option to simplify exclude these
libraries from the exports file.
show more ...
|
#
2430a354 |
| 27-Jun-2024 |
shaw young <58664393+shawbyoung@users.noreply.github.com> |
[BOLT][NFC] Move CallGraph from Passes to Core (#96922)
Moved CallGraph and BinaryFunctionCallGraph from Passes to
Core for future use in stale matching.
|
#
2a6efe6a |
| 06-Jun-2024 |
Sayhaan Siddiqui <49014204+sayhaan@users.noreply.github.com> |
[BOLT][DWARF][NFC] Refactor GDB Index into a new file (#94405)
Create a new class and file for functions that update GDB index.
|
#
6de5fcc7 |
| 26-Feb-2024 |
Alexander Yermolovich <43973793+ayermolo@users.noreply.github.com> |
[BOLT][DWARF] Add support for .debug_names (#81062)
DWARF5 spec supports the .debug_names acceleration table. This is the
formalized version of combination of gdb-index/pubnames/types. Added
imple
[BOLT][DWARF] Add support for .debug_names (#81062)
DWARF5 spec supports the .debug_names acceleration table. This is the
formalized version of combination of gdb-index/pubnames/types. Added
implementation of it to BOLT. It supports both monolothic and split
dwarf, with and without Type Units. It does not include parent indices.
This will be in followup PR. Unlike LLVM output this will put all the
CUs and TUs into one Module.
show more ...
|
#
23c8d382 |
| 21-Aug-2023 |
Job Noorman <jnoorman@igalia.com> |
[BOLT] Calculate input to output address map using BOLTLinker
BOLT uses MCAsmLayout to calculate the output values of basic blocks. This means output values are calculated based on a pre-linking sta
[BOLT] Calculate input to output address map using BOLTLinker
BOLT uses MCAsmLayout to calculate the output values of basic blocks. This means output values are calculated based on a pre-linking state and any changes to symbol values during linking will cause incorrect values to be used.
This issue was first addressed in D154604 by adding all basic block symbols to the symbol table for the linker to resolve them. However, the runtime overhead of handling this huge symbol table turned out to be prohibitively large.
This patch solves the issue in a different way. First, a temporary section containing [input address, output symbol] pairs is emitted to the intermediary object file. The linker will resolve all these references so we end up with a section of [input address, output address] pairs. This section is then parsed and used to: - Replace BinaryBasicBlock::OffsetTranslationTable - Replace BinaryFunction::InputOffsetToAddressMap - Update BinaryBasicBlock::OutputAddressRange
Note that the reason this is more performant than the previous attempt is that these symbol references do not cause entries to be added to the symbol table. Instead, section-relative references are used for the relocations.
Reviewed By: maksfb
Differential Revision: https://reviews.llvm.org/D155604
show more ...
|
#
87fb0ea2 |
| 12-Sep-2022 |
Rui Zhong <reversezr33@gmail.com> |
[BOLT][DWARF] Implement new mechanism for DWARFRewriter
This revision implement new mechanism for DWARFRewriter. In the new mechanism, we adopt the same way with DWARFLinker did. By parsing Debug in
[BOLT][DWARF] Implement new mechanism for DWARFRewriter
This revision implement new mechanism for DWARFRewriter. In the new mechanism, we adopt the same way with DWARFLinker did. By parsing Debug information into IR, we are allowed to handle debug information more flexible. Now the debug information updating process relies on IR and IR will be written out to binary once the updating finished.
A new class was added: DIEBuilder. This class is responsible for parsing debug information and raising it to the IR level. This class is also used to write out the .debug_info and .debug_abbrev sections. Since we output brand new Abbrev section we won't need to always convert low_pc/high_pc into ranges. When conversion does happen we can also remove low_pc entry.
Reviewed By: maksfb, ayermolo
Differential Revision: https://reviews.llvm.org/D130315
show more ...
|
#
de7781ea |
| 07-Jul-2023 |
Nico Weber <thakis@chromium.org> |
Revert "[DWARF][BOLT] Implement new mechanism for DWARFRewriter"
This reverts commit 460a2244430fae192298a5fd9fa2a269e540e8c1. It breaks building on macOS, and it was landed with a review URL pointi
Revert "[DWARF][BOLT] Implement new mechanism for DWARFRewriter"
This reverts commit 460a2244430fae192298a5fd9fa2a269e540e8c1. It breaks building on macOS, and it was landed with a review URL pointing to some Facebook-internal service.
Also reverts a bunch of follow-ups:
Revert "[BOLT][DWARF] Don't check string offsets" This reverts commit f9d6f48c8bf5acaac07502403c41cf0b0d89c8d2.
Revert "[BOLT][DWARF] Change to process and write out TUs first then CUs in batches" This reverts commit 88e95c1e4bb6e2ad3bfd185b96341ad5c09eff6b.
Revert "[BOLT][DWARF] Output DWO files as they are being processed" This reverts commit 46ca2e3fcd419b1246357ed3b9cd36630f16e64d.
Revert "[BOLT][DWARF] Don't check string offsets" This reverts commit cfe4a4b04f219a9dbb4e3fc01883437b6ff0e702.
Revert "[BOLT][DWARF] Numerous fixes for a new DWARFRewriter" This reverts commit 2701a661daa393ad5901ac88d420d7aa931eda0d.
show more ...
|
#
460a2244 |
| 12-Sep-2022 |
Alexander Yermolovich <ayermolo@meta.com> |
[DWARF][BOLT] Implement new mechanism for DWARFRewriter
Summary: This revision implement new mechanism for DWARFRewriter. In the new mechanism, we adopt the same way with DWARFLinker did. By parsing
[DWARF][BOLT] Implement new mechanism for DWARFRewriter
Summary: This revision implement new mechanism for DWARFRewriter. In the new mechanism, we adopt the same way with DWARFLinker did. By parsing Debug information into IR, we are allowed to handle debug information more flexible. Now the debug information updating process relies on IR and IR will be written out to binary once the updating finished.
A new class was added: DIEBuilder. This class is responsible for parsing debug information and raising it to the IR level. This class is also used to write out the .debug_info and .debug_abbrev sections. Since we output brand new Abbrev section we won't need to always convert low_pc/high_pc into ranges. When conversion does happen we can also remove low_pc entry.
Differential Revision: https://phabricator.intern.facebook.com/D39484421
Tasks: T117448832
show more ...
|
#
3e3a926b |
| 16-Feb-2023 |
spupyrev <spupyrev@fb.com> |
[BOLT][NFC] Add hash computation for basic blocks
Extending yaml profile format with block hashes, which are used for stale profile matching. To avoid duplication of the code, created a new class wi
[BOLT][NFC] Add hash computation for basic blocks
Extending yaml profile format with block hashes, which are used for stale profile matching. To avoid duplication of the code, created a new class with a collection of utilities for computing hashes.
Reviewed By: Amir
Differential Revision: https://reviews.llvm.org/D144306
show more ...
|
#
f09cf34d |
| 20-Dec-2022 |
Archibald Elliott <archibald.elliott@arm.com> |
[Support] Move TargetParsers to new component
This is a fairly large changeset, but it can be broken into a few pieces: - `llvm/Support/*TargetParser*` are all moved from the LLVM Support componen
[Support] Move TargetParsers to new component
This is a fairly large changeset, but it can be broken into a few pieces: - `llvm/Support/*TargetParser*` are all moved from the LLVM Support component into a new LLVM Component called "TargetParser". This potentially enables using tablegen to maintain this information, as is shown in https://reviews.llvm.org/D137517. This cannot currently be done, as llvm-tblgen relies on LLVM's Support component. - This also moves two files from Support which use and depend on information in the TargetParser: - `llvm/Support/Host.{h,cpp}` which contains functions for inspecting the current Host machine for info about it, primarily to support getting the host triple, but also for `-mcpu=native` support in e.g. Clang. This is fairly tightly intertwined with the information in `X86TargetParser.h`, so keeping them in the same component makes sense. - `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains the target triple parser and representation. This is very intertwined with the Arm target parser, because the arm architecture version appears in canonical triples on arm platforms. - I moved the relevant unittests to their own directory.
And so, we end up with a single component that has all the information about the following, which to me seems like a unified component: - Triples that LLVM Knows about - Architecture names and CPUs that LLVM knows about - CPU detection logic for LLVM
Given this, I have also moved `RISCVISAInfo.h` into this component, as it seems to me to be part of that same set of functionality.
If you get link errors in your components after this patch, you likely need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.
Differential Revision: https://reviews.llvm.org/D137838
show more ...
|
#
61cff907 |
| 22-Sep-2022 |
serge-sans-paille <sguelton@redhat.com> |
[BOLT] Support building bolt when LLVM_LINK_LLVM_DYLIB is ON
This does *not* link with libLLVM, but with static archives instead. Not super-great, but at least the build works, which is probably bet
[BOLT] Support building bolt when LLVM_LINK_LLVM_DYLIB is ON
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
show more ...
|
#
8477bc67 |
| 17-Jul-2022 |
Fabian Parzefall <parzefall@fb.com> |
[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 ...
|
#
e290133c |
| 23-Feb-2022 |
Maksim Panchenko <maks@fb.com> |
[BOLT] Add new class for symbolizing X86 instructions
Summary: While disassembling instructions, we need to replace certain immediate operands with symbols. This symbolizing process relies on readin
[BOLT] Add new class for symbolizing X86 instructions
Summary: While disassembling instructions, we need to replace certain immediate operands with symbols. This symbolizing process relies on reading relocations against instructions. However, some X86 instructions can have multiple immediate operands and up to two relocations against them. Thus, correctly matching a relocation to an operand is not always possible without knowing the operand offset within the instruction.
Luckily, LLVM provides an interface for passing the required info from the disassembler via a virtual MCSymbolizer class. Creating a target-specific version allows a precise matching of relocations to operands.
This diff adds X86MCSymbolizer class that performs X86-specific symbolizing (currently limited to non-branch instructions).
Reviewers: yota9, Amir, ayermolo, rafauler, zr33
Differential Revision: https://reviews.llvm.org/D120928
show more ...
|
#
bdba3d09 |
| 13-May-2022 |
Amir Ayupov <aaupov@users.noreply.github.com> |
[BOLT][CMAKE] Fix DYLIB build
Move BOLT libraries out of `LLVM_LINK_COMPONENTS` to `target_link_libraries`. Addresses issue #55432.
Reviewed By: rafauler
Differential Revision: https://reviews.llv
[BOLT][CMAKE] Fix DYLIB build
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
show more ...
|
#
2ccea6ea |
| 16-Nov-2021 |
Rafael Auler <rafaelauler@fb.com> |
Fix shared build
Summary: We were not tracking -DBUILD_SHARED_LIBS=ON and we introduced some commits that break that by not specifying the correct dependencies. Fix that.
(cherry picked from FBD324
Fix shared build
Summary: We were not tracking -DBUILD_SHARED_LIBS=ON and we introduced some commits that break that by not specifying the correct dependencies. Fix that.
(cherry picked from FBD32453377)
show more ...
|
#
a34c753f |
| 08-Oct-2021 |
Rafael Auler <rafaelauler@fb.com> |
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 ...
|