[IR] Remove unused includes (NFC) (#114679)

Identified with misc-include-cleaner.

ProfDataUtils: Avoid dyn_extract + assert (NFC)

[llvm][ProfDataUtils] Provide getNumBranchWeights API (#90146)

As suggested in
https://github.com/llvm/llvm-project/pull/86609/files#r1556689262
an API for getting the number of branch weights dir

[llvm][ProfDataUtils] Provide getNumBranchWeights API (#90146)

As suggested in
https://github.com/llvm/llvm-project/pull/86609/files#r1556689262
an API for getting the number of branch weights directly from the MD
node would be useful in a variety of checks, and keeps the logic within
ProfDataUtils.

show more ...

Reapply "[llvm][IR] Extend BranchWeightMetadata to track provenance o… (#95281)

…f weights" #95136

Reverts #95060, and relands #86609, with the unintended code generation
changes addressed.

T

Reapply "[llvm][IR] Extend BranchWeightMetadata to track provenance o… (#95281)

…f weights" #95136

Reverts #95060, and relands #86609, with the unintended code generation
changes addressed.

This patch implements the changes to LLVM IR discussed in
https://discourse.llvm.org/t/rfc-update-branch-weights-metadata-to-allow-tracking-branch-weight-origins/75032

In this patch, we add an optional field to MD_prof meatdata nodes for
branch weights, which can be used to distinguish weights added from
llvm.expect* intrinsics from those added via other methods, e.g. from
profiles or inserted by the compiler.

One of the major motivations, is for use with MisExpect diagnostics,
which need to know if branch_weight metadata originates from an
llvm.expect intrinsic. Without that information, we end up checking
branch weights multiple times in the case if ThinLTO + SampleProfiling,
leading to some inaccuracy in how we report MisExpect related
diagnostics to users.

Since we change the format of MD_prof metadata in a fundamental way, we
need to update code handling branch weights in a number of places.

We also update the lang ref for branch weights to reflect the change.

show more ...

Revert "[llvm][IR] Extend BranchWeightMetadata to track provenance of weights" (#95060)

Reverts llvm/llvm-project#86609

This change causes compile-time regressions for stage2 builds
(https://llv

Revert "[llvm][IR] Extend BranchWeightMetadata to track provenance of weights" (#95060)

Reverts llvm/llvm-project#86609

This change causes compile-time regressions for stage2 builds
(https://llvm-compile-time-tracker.com/compare.php?from=3254f31a66263ea9647c9547f1531c3123444fcd&to=c5978f1eb5eeca8610b9dfce1fcbf1f473911cd8&stat=instructions:u).
It also introduced unintended changes to `.text` which should be
addressed before relanding.

show more ...

[llvm][IR] Extend BranchWeightMetadata to track provenance of weights (#86609)

This patch implements the changes to LLVM IR discussed in

https://discourse.llvm.org/t/rfc-update-branch-weights-met

[llvm][IR] Extend BranchWeightMetadata to track provenance of weights (#86609)

This patch implements the changes to LLVM IR discussed in

https://discourse.llvm.org/t/rfc-update-branch-weights-metadata-to-allow-tracking-branch-weight-origins/75032

In this patch, we add an optional field to MD_prof metadata nodes for
branch weights, which can be used to distinguish weights added from
`llvm.expect*` intrinsics from those added via other methods, e.g.
from profiles or inserted by the compiler.

One of the major motivations, is for use with MisExpect diagnostics,
which need to know if branch_weight metadata originates from an
llvm.expect intrinsic. Without that information, we end up checking
branch weights multiple times in the case if ThinLTO + SampleProfiling,
leading to some inaccuracy in how we report MisExpect related
diagnostics to users.

Since we change the format of MD_prof metadata in a fundamental way, we
need to update code handling branch weights in a number of places.

We also update the lang ref for branch weights to reflect the change.

show more ...

[Inline][PGO] After inline, update InvokeInst profile counts in caller and cloned callee (#83809)

A related change is https://reviews.llvm.org/D133121, which correctly
preserves both branch weights

[Inline][PGO] After inline, update InvokeInst profile counts in caller and cloned callee (#83809)

A related change is https://reviews.llvm.org/D133121, which correctly
preserves both branch weights and value profiles for invoke instruction.
* If the branch weight of the `invokeinst` specifies taken / not-taken branches, there is no scale.

show more ...

[llvm][profdata][NFC] Support 64-bit weights in ProfDataUtils (#86607)

Since some places, like SimplifyCFG, work with 64-bit weights, we supply
an API in ProfDataUtils to extract the weights accord

[llvm][profdata][NFC] Support 64-bit weights in ProfDataUtils (#86607)

Since some places, like SimplifyCFG, work with 64-bit weights, we supply
an API in ProfDataUtils to extract the weights accordingly.

We change the API slightly to disambiguate the 64-bit version from the
32-bit version.

show more ...

[IR] Use StringRef::operator== instead of StringRef::equals (NFC) (#90550)

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

- StringRef::operator== outnumbers StringRe

[IR] Use StringRef::operator== instead of StringRef::equals (NFC) (#90550)

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

- StringRef::operator== outnumbers StringRef::equals by a factor of 22
under llvm/ 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 ...

[nfc][PGO]Factor out profile scaling into a standalone helper function (#83780)

- Put the helper function in `ProfDataUtil.h/cpp`, which is already a
dependency of `Instructions.cpp`
- The helper

[nfc][PGO]Factor out profile scaling into a standalone helper function (#83780)

- Put the helper function in `ProfDataUtil.h/cpp`, which is already a
dependency of `Instructions.cpp`
- The helper function could be re-used to update profiles of
`InvokeInst` (in a follow-up pull request)

show more ...

Revert "[IR] Use range-based for loops (NFC)"

This reverts commit e8512786fedbfa6ddba70ceddc29d7122173ba5e.

This revert is done because llvm::drop_begin over an empty ArrayRef
doesn't return an emp

Revert "[IR] Use range-based for loops (NFC)"

This reverts commit e8512786fedbfa6ddba70ceddc29d7122173ba5e.

This revert is done because llvm::drop_begin over an empty ArrayRef
doesn't return an empty range, and therefore can lead to an invalid
address returned instead.

See discussion in https://github.com/llvm/llvm-project/pull/80737 for
more context.

show more ...

[IR] Use range-based for loops (NFC)

[llvm] Use Instruction::hasMetadata (NFC)

Add setBranchWeigths convenience function. NFC (#72446)

Add `setBranchWeights` convenience function to ProfDataUtils.h and use
it where appropriate.

ProfDataUtils: Add extractFromBranchWeightMD function; NFC

Expose internal helper function as new `extractFromBranchWeightMD` API.

Differential revision: https://reviews.llvm.org/D157937

[llvm][ir] Purge MD_prof custom accessors

This commit purges direct accesses to MD_prof metadata and replaces them
with the accessors provided from the utility file wherever possible.
This commit ca

[llvm][ir] Purge MD_prof custom accessors

This commit purges direct accesses to MD_prof metadata and replaces them
with the accessors provided from the utility file wherever possible.
This commit can be seen as the first step towards switching the branch weights to 64 bits.
See post here: https://discourse.llvm.org/t/extend-md-prof-branch-weights-metadata-from-32-to-64-bits/67492

Reviewed By: davidxl, paulkirth

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

show more ...

[llvm][ir][NFC] Clean up "if after return" in ProfDataUtils.cpp

Reviewed By: tejohnson

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

[llvm][ir] Add missing license to ProfDataUtils

We failed to add these in D128860 or D128858

Reviewed By: davidxl

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

[llvm] Provide utility function for MD_prof

Currently, there is significant code duplication for dealing with
MD_prof metadata throughout the compiler. These utility functions can
improve code reuse

[llvm] Provide utility function for MD_prof

Currently, there is significant code duplication for dealing with
MD_prof metadata throughout the compiler. These utility functions can
improve code reuse and simplify boilerplate code when dealing with
profiling metadata, such as branch weights. The inent is to provide a
uniform set of APIs that allow common tasks, such as identifying
specific types of MD_prof metadata and extracting branch weights.

Future patches can build on this initial implementation and clean up the
different implementations across the compiler.

Reviewed By: bogner

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

show more ...