[BOLT][NFC] Const-ify getDynamicRelocationAt

Reviewed By: #bolt, maksfb

Differential Revision: https://reviews.llvm.org/D152662

[BOLT] Add isParentOf and isParentOrChildOf BF checks

Add helper methods and simplify cases where we want to check if two functions
are parent-child of each other (function-fragment relationship).

[BOLT] Add isParentOf and isParentOrChildOf BF checks

Add helper methods and simplify cases where we want to check if two functions
are parent-child of each other (function-fragment relationship).

Reviewed By: #bolt, rafauler

Differential Revision: https://reviews.llvm.org/D142668

show more ...

[MC] Always encode instruction into SmallVector

All users of MCCodeEmitter::encodeInstruction use a raw_svector_ostream
to encode the instruction into a SmallVector. The raw_ostream however
incurs s

[MC] Always encode instruction into SmallVector

All users of MCCodeEmitter::encodeInstruction use a raw_svector_ostream
to encode the instruction into a SmallVector. The raw_ostream however
incurs some overhead for the actual encoding.

This change allows an MCCodeEmitter to directly emit an instruction into
a SmallVector without using a raw_ostream and therefore allow for
performance improvments in encoding. A default path that uses existing
raw_ostream implementations is provided.

Reviewed By: MaskRay, Amir

Differential Revision: https://reviews.llvm.org/D145791

show more ...

[BOLT] Improve dynamic relocations support for CI

This patch fixes few problems with supporting dynamic relocations in CI.
1. After dynamic relocations and functions were read search for dynamic
rel

[BOLT] Improve dynamic relocations support for CI

This patch fixes few problems with supporting dynamic relocations in CI.
1. After dynamic relocations and functions were read search for dynamic
relocations located in functions. Currently we expected them only to be
relative and only to be in constant island. Mark islands of such
functions to have dynamic relocations and create CI access symbol on the
relocation offset, so the BD would be created for such place.
2. During function disassemble and handling address reference for
constant island check if the referred external CI has dynamic
relocation. And if it has one we would continue to refer original CI
rather then creating a local copy.
3. After function disassembly stage mark function that has dynamic reloc
in CI as non-simple. We don't want such functions to be optimized, since
such passes as split function would create 2 copies of CI which we
unable to support currently.
4. During updating output values for BF search for BD located in CI and
update their output locations.
5. On dynamic relocation patching stage search for binary data located
on relocation offset. If it was moved use new relocation offset value
rather then an old one.

Vladislav Khmelevsky,
Advanced Software Technology Lab, Huawei

Differential Revision: https://reviews.llvm.org/D143748

show more ...

[BOLT][NFC] Const-ify analyzeJumpTable

Avoid modifying `BF`, instead set extra output parameter and modify BF in caller
scope.

Reviewed By: #bolt, rafauler

Differential Revision: https://reviews.l

[BOLT][NFC] Const-ify analyzeJumpTable

Avoid modifying `BF`, instead set extra output parameter and modify BF in caller
scope.

Reviewed By: #bolt, rafauler

Differential Revision: https://reviews.llvm.org/D144598

show more ...

[BOLT] Change call count output for ICF

ICF optimization runs multiple passes and the order in which functions
are folded could be dependent on the order they are being processed.
This order is inde

[BOLT] Change call count output for ICF

ICF optimization runs multiple passes and the order in which functions
are folded could be dependent on the order they are being processed.
This order is indeterministic as functions are intermediately stored in
std::unordered_map<>. Note that this order is mostly stable, but is not
guaranteed to be and can change e.g. after switching to a different C++
library implementation.

Because the processing (and folding) order is indeterministic, the
previous way of calculating merged function call count could produce
different results.

Change the way we calculate the ICF call count to make it independent of
the function folding/processing order.

Mostly NFC as the output binary should remain the same, the change
affects only the console output.

Reviewed By: yota9

Differential Revision: https://reviews.llvm.org/D144807

show more ...

[BOLT] Rename BF::isParentFragment -> isChildOf

`isChildOf` is a more concise name for the check. Also, there's no need to
test if the function is a fragment before doing `isChildOf` check.

Reviewe

[BOLT] Rename BF::isParentFragment -> isChildOf

`isChildOf` is a more concise name for the check. Also, there's no need to
test if the function is a fragment before doing `isChildOf` check.

Reviewed By: #bolt, rafauler, maksfb

Differential Revision: https://reviews.llvm.org/D142667

show more ...

[BOLT] Process fragment siblings in lite mode, keep lite mode on

In lite mode, include split function fragments to the list of functions to
process even if a fragment has no samples. This is require

[BOLT] Process fragment siblings in lite mode, keep lite mode on

In lite mode, include split function fragments to the list of functions to
process even if a fragment has no samples. This is required to properly
detect and update split jump tables (jump tables that contain pointers to code
in the main and cold fragments).

Reviewed By: #bolt, maksfb

Differential Revision: https://reviews.llvm.org/D140457

show more ...

[BOLT][NFC] Use llvm::make_second_range

Reviewed By: #bolt, rafauler

Differential Revision: https://reviews.llvm.org/D143019

[BOLT][DWARF] Add logging for split dwarf

Added logging when bolt is processing binary with split dwarf.

Reviewed By: rafauler

Differential Revision: https://reviews.llvm.org/D142576

[BOLT][NFC] Use std::optional in BC

[BOLT][NFC] Use std::optional in MCPlusBuilder

Reviewed By: maksfb, #bolt

Differential Revision: https://reviews.llvm.org/D139260

[DebugInfo] llvm::Optional => std::optional

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

[MC] llvm::Optional => std::optional

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

[BOLT] Fix after DebugInfoMetadata change 0ca43d44888885d6caf7636db91fe810e822263c

[BOLT] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of ma

[BOLT] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[bolt] Use llvm::sys::RWMutex instead of std::shared_timed_mutex

This has the following advantages:
- std::shared_timed_mutex is macOS 10.12+ only. llvm::sys::RWMutex
automatically switches to a d

[bolt] Use llvm::sys::RWMutex instead of std::shared_timed_mutex

This has the following advantages:
- std::shared_timed_mutex is macOS 10.12+ only. llvm::sys::RWMutex
automatically switches to a different implementation internally
when targeting older macOS versions.
- bolt only needs std::shared_mutex, not std::shared_timed_mutex.
llvm::sys::RWMutex automatically uses std::shared_mutex internally
where available.

std::shared_mutex and RWMutex have the same API, so no code changes
other than types and includes are needed.

Differential Revision: https://reviews.llvm.org/D138423

show more ...

Use None consistently (NFC)

This patch replaces NoneType() and NoneType::None with None in
preparation for migration from llvm::Optional to std::optional.

In the std::optional world, we are not gur

Use None consistently (NFC)

This patch replaces NoneType() and NoneType::None with None in
preparation for migration from llvm::Optional to std::optional.

In the std::optional world, we are not guranteed to be able to
default-construct std::nullopt_t or peek what's inside it, so neither
NoneType() nor NoneType::None has a corresponding expression in the
std::optional world.

Once we consistently use None, we should even be able to replace the
contents of llvm/include/llvm/ADT/None.h with something like:

using NoneType = std::nullopt_t;
inline constexpr std::nullopt_t None = std::nullopt;

to ease the migration from llvm::Optional to std::optional.

Differential Revision: https://reviews.llvm.org/D138376

show more ...

[bolt] Fix std::prev()-past-begin in veneer handling code

matchLinkerVeneer() returns 3 if `Instruction` and the last
two instructions in `[Instructions.begin, Instructions.end())`
match the pattern

[bolt] Fix std::prev()-past-begin in veneer handling code

matchLinkerVeneer() returns 3 if `Instruction` and the last
two instructions in `[Instructions.begin, Instructions.end())`
match the pattern

ADRP x16, imm
ADD x16, x16, imm
BR x16

BinaryContext.cpp used to use

--Count;
for (auto It = std::prev(Instructions.end()); Count != 0;
It = std::prev(It), --Count) {
...use It...
}

to walk these instructions. The first `--Count` skips the
instruction that's in `Instruction` instead of in `Instructions`.
The loop then walks over `Instructions`.

However, on the last iteration, this calls `std::prev()` on an
iterator that points at the container's begin(), which can blow
up.

Instead, use rbegin(), which sidesteps this issue.

Fixes test/AArch64/veneer-gold.s on a macOS host.
With this, check-bolt passes on macOS.

Differential Revision: https://reviews.llvm.org/D138313

show more ...

[BOLT][NFC] Fix possible use-after-free

If NewName twine has reference to the old name, then after
Section.Name = NewName.str(); this reference is invalidated,
so we cannot use NewName.str() anymore

[BOLT][NFC] Fix possible use-after-free

If NewName twine has reference to the old name, then after
Section.Name = NewName.str(); this reference is invalidated,
so we cannot use NewName.str() anymore.

Reviewed By: rafauler

Differential Revision: https://reviews.llvm.org/D137616

show more ...

[BOLT] Fix instruction encoding validation

Always use non-symbolizing disassembler for instruction encoding
validation as symbols will be treated as undefined/zeros be the encoder
and causing byte s

[BOLT] Fix instruction encoding validation

Always use non-symbolizing disassembler for instruction encoding
validation as symbols will be treated as undefined/zeros be the encoder
and causing byte sequence mismatches.

Reviewed By: Amir

Differential Revision: https://reviews.llvm.org/D136118

show more ...

[BOLT] Section-handling refactoring/overhaul

Simplify the logic of handling sections in BOLT. This change brings more
direct and predictable mapping of BinarySection instances to sections in
the inp

[BOLT] Section-handling refactoring/overhaul

Simplify the logic of handling sections in BOLT. This change brings more
direct and predictable mapping of BinarySection instances to sections in
the input and output files.

* Only sections from the input binary will have a non-null SectionRef.
When a new section is created as a copy of the input section,
its SectionRef is reset to null.

* RewriteInstance::getOutputSectionName() is removed as the section name
in the output file is now defined by BinarySection::getOutputName().

* Querying BinaryContext for sections by name uses their original name.
E.g., getUniqueSectionByName(".rodata") will return the original
section even if the new .rodata section was created.

* Input file sections (with relocations applied) are emitted via MC with
".bolt.org" prefix. However, their name in the output binary is
unchanged unless a new section with the same name is created.

* New sections are emitted internally with ".bolt.new" prefix if there's
a name conflict with an input file section. Their original name is
preserved in the output file.

* Section header string table is properly populated with section names
that are actually used. Previously we used to include discarded
section names as well.

* Fix the problem when dynamic relocations were propagated to a new
section with a name that matched a section in the input binary.
E.g., the new .rodata with jump tables had dynamic relocations from
the original .rodata.

Reviewed By: rafauler

Differential Revision: https://reviews.llvm.org/D135494

show more ...

[BOLT][NFC] Refactor creation of symbol+addend references

Put code that creates references to symbol+addend behind MCPlusBuilder.
Will use this later in validate memory references pass.

Reviewed By

[BOLT][NFC] Refactor creation of symbol+addend references

Put code that creates references to symbol+addend behind MCPlusBuilder.
Will use this later in validate memory references pass.

Reviewed By: #bolt, maksfb, yota9

Differential Revision: https://reviews.llvm.org/D134097

show more ...

[BOLT] Preserve original LSDA type encoding

In non-pie binaries BOLT unconditionally converted type encoding
from indirect to absptr, which broke std exceptions since pointers
to their typeinfo were

[BOLT] Preserve original LSDA type encoding

In non-pie binaries BOLT unconditionally converted type encoding
from indirect to absptr, which broke std exceptions since pointers
to their typeinfo were only assigned at runtime in .data section.
In this patch we preserve original encoding so that indirect
remains indirect and can be resolved at runtime, and absolute remains absolute.

Reviewed By: rafauler, maksfb

Differential Revision: https://reviews.llvm.org/D132484

show more ...

[BOLT][AArch64] Handle references to the middle of Constant Islands

Fix BinaryContext::handleAddressRef to properly detect references to
other function's Constant islands.

Revieved By: rafauler, yo

[BOLT][AArch64] Handle references to the middle of Constant Islands

Fix BinaryContext::handleAddressRef to properly detect references to
other function's Constant islands.

Revieved By: rafauler, yota9

Differential Revision: https://reviews.llvm.org/D132376

show more ...