History log of /llvm-project/bolt/lib/Core/CMakeLists.txt (Results 1 – 16 of 16)
Revision Date Author Comments
# 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 ...