[BOLT][NFC] Make estimateEdgeCounts a BinaryFunctionPass (#93074)

[BOLT] Allow pass-through blocks in YAMLProfileReader (#91828)

Use StringRef::operator== instead of StringRef::equals (NFC) (#91864)

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator==/!= outnumber StringRef::

Use StringRef::operator== instead of StringRef::equals (NFC) (#91864)

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator==/!= outnumber StringRef::equals by a factor of
276 under llvm-project/ in terms of their usage.

- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.

- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".

show more ...

[BOLT][NFC] Clean includes, add license headers (#87200)

[BOLT] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,end

[BOLT] Use StringRef::{starts,ends}_with (NFC)

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.

show more ...

[BOLT] Make instruction size a first-class annotation (#72167)

When NOP instructions are used to reserve space in the code, e.g. for
patching, it becomes critical to preserve their original size wh

[BOLT] Make instruction size a first-class annotation (#72167)

When NOP instructions are used to reserve space in the code, e.g. for
patching, it becomes critical to preserve their original size while
emitting the code. On x86, we rely on "Size" annotation for NOP
instructions size, as the original instruction size is lost in the
disassembly/assembly process.

This change makes instruction size a first-class annotation and is
affectively NFCI. A follow-up diff will use the annotation for code
emission.

show more ...

[BOLT][NFC] Use formatv in DataAggregator/DataReader prints

Reviewed By: #bolt, maksfb

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

[BOLT][NFC] Use llvm::make_range

Use `llvm::make_range` convenience wrapper from ADT.

Reviewed By: #bolt, rafauler

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

[BOLT] Remove dependency on StringMap iteration order

Remove the usage of StringMap in places where the iteration order
affects the output since the iteration over StringMap is
non-deterministic.

R

[BOLT] Remove dependency on StringMap iteration order

Remove the usage of StringMap in places where the iteration order
affects the output since the iteration over StringMap is
non-deterministic.

Reviewed By: Amir

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

show more ...

[BOLT][NFC] Move getLTOCommonName to Utils

Reuse getLTOCommonName in components other than Profile (to be used in Core)

Reviewed By: #bolt, maksfb

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

[BOLT][NFC] Move getLTOCommonName to Utils

Reuse getLTOCommonName in components other than Profile (to be used in Core)

Reviewed By: #bolt, maksfb

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

show more ...

[BOLT] Handle __uniq suffix added by -funique-internal-linkage-names

In profile matching, if `.__uniq` suffix added for internal linkage
symbols with `-funique-internal-linkage-names` prevents BOLT

[BOLT] Handle __uniq suffix added by -funique-internal-linkage-names

In profile matching, if `.__uniq` suffix added for internal linkage
symbols with `-funique-internal-linkage-names` prevents BOLT from
matching to a binary function, try to strip the suffix and perform
fuzzy name matching.

Follow-up to D124117.

Reviewed By: #bolt, maksfb

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

show more ...

[BOLT][NFC] Use llvm::reverse

Use llvm::reverse instead of `for (auto I = rbegin(), E = rend(); I != E; ++I)`

Reviewed By: #bolt, rafauler

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

[BOLT] Check no-LBR samples in mayHaveProfileData

No-LBR mode wasn't tested and slipped when mayHaveProfileData was added for
Lite mode. This enables processing of profiles collected without LBR and

[BOLT] Check no-LBR samples in mayHaveProfileData

No-LBR mode wasn't tested and slipped when mayHaveProfileData was added for
Lite mode. This enables processing of profiles collected without LBR and
converted with `perf2bolt -nl` option.

Test Plan:
bin/llvm-lit -a tools/bolt/test/X86/nolbr.s
https://github.com/rafaelauler/bolt-tests/pull/20

Reviewed By: #bolt, rafauler

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

show more ...

[BOLT][NFC] Use std::optional for getLTOCommonName

[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 ...

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] Towards FunctionLayout const-correctness

A const-qualified reference to function layout allows accessing
non-const qualified basic blocks on a const-qualified function. This
patch adds or rem

[BOLT] Towards FunctionLayout const-correctness

A const-qualified reference to function layout allows accessing
non-const qualified basic blocks on a const-qualified function. This
patch adds or removes const-qualifiers where necessary to indicate where
basic blocks are used in a non-const manner.

Reviewed By: rafauler

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

show more ...

Revert "[BOLT] Towards FunctionLayout const-correctness"

This reverts commit 587d2653420d75ef10f30bd612d86f1e08fe9ea7.

[BOLT] Towards FunctionLayout const-correctness

A const-qualified reference to function layout allows accessing
non-const qualified basic blocks on a const-qualified function. This
patch adds or rem

[BOLT] Towards FunctionLayout const-correctness

A const-qualified reference to function layout allows accessing
non-const qualified basic blocks on a const-qualified function. This
patch adds or removes const-qualifiers where necessary to indicate where
basic blocks are used in a non-const manner.

Reviewed By: rafauler

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

show more ...

[BOLT] Use boolean literals (NFC)

Identified with modernize-use-bool-literals.

[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 ...

[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 ...

[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

[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 ...

[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 ...