-
Notifications
You must be signed in to change notification settings - Fork 14.6k
[CodeGen][StaticDataPartitioning]Place local-linkage global variables in hot or unlikely prefixed sections based on profile information #125756
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
mingmingl-llvm
merged 12 commits into
main
from
users/mingmingl-llvm/spr/globalvariables
Mar 28, 2025
Merged
Changes from all commits
Commits
Show all changes
12 commits
Select commit
Hold shift + click to select a range
8eea1ea
[CodeGen][StaticDataPartitioning]Place module-internal global variabl…
mingmingl-llvm 93d9881
add comment for bss22 and data3
mingmingl-llvm 5cbe8f8
run 'git merge main'
mingmingl-llvm 8f21570
apply code review suggestions
mingmingl-llvm f07d34d
record global variable section prefix updates as module updates
mingmingl-llvm 4e096e9
merge with main, and resolve code review comments
mingmingl-llvm 4a2a881
remove blank line
mingmingl-llvm 1f50494
Implement module-wide analysis of global variable hotness.
mingmingl-llvm 967dc03
run 'git merge main'
mingmingl-llvm 9302b2b
port code de-duplication based on feedback in the follow up patch (ht…
mingmingl-llvm 97103c6
resolve comments
mingmingl-llvm 38c8a03
resolve comments
mingmingl-llvm File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,75 @@ | ||
#ifndef LLVM_ANALYSIS_STATICDATAPROFILEINFO_H | ||
#define LLVM_ANALYSIS_STATICDATAPROFILEINFO_H | ||
|
||
#include "llvm/ADT/DenseMap.h" | ||
#include "llvm/ADT/DenseSet.h" | ||
#include "llvm/Analysis/ProfileSummaryInfo.h" | ||
#include "llvm/IR/Constant.h" | ||
#include "llvm/Pass.h" | ||
|
||
namespace llvm { | ||
|
||
/// A class that holds the constants that represent static data and their | ||
/// profile information and provides methods to operate on them. | ||
class StaticDataProfileInfo { | ||
public: | ||
/// Accummulate the profile count of a constant that will be lowered to static | ||
/// data sections. | ||
DenseMap<const Constant *, uint64_t> ConstantProfileCounts; | ||
|
||
/// Keeps track of the constants that are seen at least once without profile | ||
/// counts. | ||
DenseSet<const Constant *> ConstantWithoutCounts; | ||
|
||
/// If \p C has a count, return it. Otherwise, return std::nullopt. | ||
std::optional<uint64_t> getConstantProfileCount(const Constant *C) const; | ||
|
||
public: | ||
StaticDataProfileInfo() = default; | ||
|
||
/// If \p Count is not nullopt, add it to the profile count of the constant \p | ||
/// C in a saturating way, and clamp the count to \p getInstrMaxCountValue if | ||
/// the result exceeds it. Otherwise, mark the constant as having no profile | ||
/// count. | ||
void addConstantProfileCount(const Constant *C, | ||
std::optional<uint64_t> Count); | ||
|
||
/// Return a section prefix for the constant \p C based on its profile count. | ||
/// - If a constant doesn't have a counter, return an empty string. | ||
/// - Otherwise, | ||
/// - If it has a hot count, return "hot". | ||
/// - If it is seen by unprofiled function, return an empty string. | ||
/// - If it has a cold count, return "unlikely". | ||
/// - Otherwise (e.g. it's used by lukewarm functions), return an empty | ||
/// string. | ||
StringRef getConstantSectionPrefix(const Constant *C, | ||
const ProfileSummaryInfo *PSI) const; | ||
}; | ||
|
||
/// This wraps the StaticDataProfileInfo object as an immutable pass, for a | ||
/// backend pass to operate on. | ||
class StaticDataProfileInfoWrapperPass : public ImmutablePass { | ||
public: | ||
static char ID; | ||
StaticDataProfileInfoWrapperPass(); | ||
bool doInitialization(Module &M) override; | ||
bool doFinalization(Module &M) override; | ||
|
||
StaticDataProfileInfo &getStaticDataProfileInfo() { return *Info; } | ||
const StaticDataProfileInfo &getStaticDataProfileInfo() const { | ||
return *Info; | ||
} | ||
|
||
/// This pass provides StaticDataProfileInfo for reads/writes but does not | ||
/// modify \p M or other analysis. All analysis are preserved. | ||
void getAnalysisUsage(AnalysisUsage &AU) const override { | ||
AU.setPreservesAll(); | ||
} | ||
|
||
private: | ||
std::unique_ptr<StaticDataProfileInfo> Info; | ||
}; | ||
|
||
} // namespace llvm | ||
|
||
#endif // LLVM_ANALYSIS_STATICDATAPROFILEINFO_H |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,72 @@ | ||
#include "llvm/Analysis/StaticDataProfileInfo.h" | ||
#include "llvm/Analysis/ProfileSummaryInfo.h" | ||
#include "llvm/IR/Constant.h" | ||
#include "llvm/IR/GlobalVariable.h" | ||
#include "llvm/InitializePasses.h" | ||
#include "llvm/ProfileData/InstrProf.h" | ||
#include <sys/types.h> | ||
|
||
using namespace llvm; | ||
void StaticDataProfileInfo::addConstantProfileCount( | ||
const Constant *C, std::optional<uint64_t> Count) { | ||
if (!Count) { | ||
ConstantWithoutCounts.insert(C); | ||
return; | ||
} | ||
uint64_t &OriginalCount = ConstantProfileCounts[C]; | ||
OriginalCount = llvm::SaturatingAdd(*Count, OriginalCount); | ||
// Clamp the count to getInstrMaxCountValue. InstrFDO reserves a few | ||
// large values for special use. | ||
if (OriginalCount > getInstrMaxCountValue()) | ||
OriginalCount = getInstrMaxCountValue(); | ||
} | ||
|
||
std::optional<uint64_t> | ||
StaticDataProfileInfo::getConstantProfileCount(const Constant *C) const { | ||
auto I = ConstantProfileCounts.find(C); | ||
if (I == ConstantProfileCounts.end()) | ||
return std::nullopt; | ||
return I->second; | ||
} | ||
|
||
StringRef StaticDataProfileInfo::getConstantSectionPrefix( | ||
const Constant *C, const ProfileSummaryInfo *PSI) const { | ||
auto Count = getConstantProfileCount(C); | ||
if (!Count) | ||
return ""; | ||
// The accummulated counter shows the constant is hot. Return 'hot' whether | ||
// this variable is seen by unprofiled functions or not. | ||
if (PSI->isHotCount(*Count)) | ||
return "hot"; | ||
// The constant is not hot, and seen by unprofiled functions. We don't want to | ||
// assign it to unlikely sections, even if the counter says 'cold'. So return | ||
// an empty prefix before checking whether the counter is cold. | ||
if (ConstantWithoutCounts.count(C)) | ||
snehasish marked this conversation as resolved.
Show resolved
Hide resolved
|
||
return ""; | ||
// The accummulated counter shows the constant is cold. Return 'unlikely'. | ||
if (PSI->isColdCount(*Count)) | ||
return "unlikely"; | ||
// The counter says lukewarm. Return an empty prefix. | ||
return ""; | ||
} | ||
|
||
bool StaticDataProfileInfoWrapperPass::doInitialization(Module &M) { | ||
Info.reset(new StaticDataProfileInfo()); | ||
return false; | ||
} | ||
|
||
bool StaticDataProfileInfoWrapperPass::doFinalization(Module &M) { | ||
Info.reset(); | ||
return false; | ||
} | ||
|
||
INITIALIZE_PASS(StaticDataProfileInfoWrapperPass, "static-data-profile-info", | ||
"Static Data Profile Info", false, true) | ||
|
||
StaticDataProfileInfoWrapperPass::StaticDataProfileInfoWrapperPass() | ||
: ImmutablePass(ID) { | ||
initializeStaticDataProfileInfoWrapperPassPass( | ||
*PassRegistry::getPassRegistry()); | ||
} | ||
|
||
char StaticDataProfileInfoWrapperPass::ID = 0; |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,109 @@ | ||
//===- StaticDataAnnotator - Annotate static data's section prefix --------===// | ||
// | ||
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. | ||
// See https://llvm.org/LICENSE.txt for license information. | ||
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception | ||
// | ||
//===----------------------------------------------------------------------===// | ||
// | ||
// To reason about module-wide data hotness in a module granularity, this file | ||
// implements a module pass StaticDataAnnotator to work coordinately with the | ||
// StaticDataSplitter pass. | ||
// | ||
// The StaticDataSplitter pass is a machine function pass. It analyzes data | ||
// hotness based on code and adds counters in StaticDataProfileInfo via its | ||
// wrapper pass StaticDataProfileInfoWrapper. | ||
// The StaticDataProfileInfoWrapper sits in the middle between the | ||
// StaticDataSplitter and StaticDataAnnotator passes. | ||
// The StaticDataAnnotator pass is a module pass. It iterates global variables | ||
// in the module, looks up counters from StaticDataProfileInfo and sets the | ||
// section prefix based on profiles. | ||
// | ||
// The three-pass structure is implemented for practical reasons, to work around | ||
snehasish marked this conversation as resolved.
Show resolved
Hide resolved
|
||
// the limitation that a module pass based on legacy pass manager cannot make | ||
// use of MachineBlockFrequencyInfo analysis. In the future, we can consider | ||
// porting the StaticDataSplitter pass to a module-pass using the new pass | ||
// manager framework. That way, analysis are lazily computed as opposed to | ||
// eagerly scheduled, and a module pass can use MachineBlockFrequencyInfo. | ||
//===----------------------------------------------------------------------===// | ||
|
||
#include "llvm/Analysis/ProfileSummaryInfo.h" | ||
#include "llvm/Analysis/StaticDataProfileInfo.h" | ||
#include "llvm/CodeGen/Passes.h" | ||
#include "llvm/IR/Analysis.h" | ||
#include "llvm/IR/Module.h" | ||
#include "llvm/IR/PassManager.h" | ||
#include "llvm/InitializePasses.h" | ||
#include "llvm/Pass.h" | ||
#include "llvm/Support/raw_ostream.h" | ||
|
||
#define DEBUG_TYPE "static-data-annotator" | ||
|
||
using namespace llvm; | ||
|
||
/// A module pass which iterates global variables in the module and annotates | ||
/// their section prefixes based on profile-driven analysis. | ||
class StaticDataAnnotator : public ModulePass { | ||
snehasish marked this conversation as resolved.
Show resolved
Hide resolved
|
||
public: | ||
static char ID; | ||
|
||
StaticDataProfileInfo *SDPI = nullptr; | ||
const ProfileSummaryInfo *PSI = nullptr; | ||
|
||
StaticDataAnnotator() : ModulePass(ID) { | ||
initializeStaticDataAnnotatorPass(*PassRegistry::getPassRegistry()); | ||
} | ||
|
||
void getAnalysisUsage(AnalysisUsage &AU) const override { | ||
AU.addRequired<StaticDataProfileInfoWrapperPass>(); | ||
AU.addRequired<ProfileSummaryInfoWrapperPass>(); | ||
AU.setPreservesAll(); | ||
ModulePass::getAnalysisUsage(AU); | ||
} | ||
|
||
StringRef getPassName() const override { return "Static Data Annotator"; } | ||
|
||
bool runOnModule(Module &M) override; | ||
}; | ||
|
||
bool StaticDataAnnotator::runOnModule(Module &M) { | ||
SDPI = &getAnalysis<StaticDataProfileInfoWrapperPass>() | ||
.getStaticDataProfileInfo(); | ||
PSI = &getAnalysis<ProfileSummaryInfoWrapperPass>().getPSI(); | ||
|
||
if (!PSI->hasProfileSummary()) | ||
return false; | ||
|
||
bool Changed = false; | ||
for (auto &GV : M.globals()) { | ||
if (GV.isDeclarationForLinker()) | ||
continue; | ||
|
||
// The implementation below assumes prior passes don't set section prefixes, | ||
// and specifically do 'assign' rather than 'update'. So report error if a | ||
// section prefix is already set. | ||
if (auto maybeSectionPrefix = GV.getSectionPrefix(); | ||
maybeSectionPrefix && !maybeSectionPrefix->empty()) | ||
llvm::report_fatal_error("Global variable " + GV.getName() + | ||
" already has a section prefix " + | ||
*maybeSectionPrefix); | ||
|
||
StringRef SectionPrefix = SDPI->getConstantSectionPrefix(&GV, PSI); | ||
if (SectionPrefix.empty()) | ||
continue; | ||
|
||
GV.setSectionPrefix(SectionPrefix); | ||
Changed = true; | ||
} | ||
|
||
return Changed; | ||
} | ||
|
||
char StaticDataAnnotator::ID = 0; | ||
|
||
INITIALIZE_PASS(StaticDataAnnotator, DEBUG_TYPE, "Static Data Annotator", false, | ||
false) | ||
|
||
ModulePass *llvm::createStaticDataAnnotatorPass() { | ||
return new StaticDataAnnotator(); | ||
} |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is reasonable to put this definition into ProfileSummaryInfo.h, as it is about summary/aggregation of const profiles.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, I don't feel strong about having new classes in
ProfileSummaryInfo.h
or in new files. Actually I once thought about the former and hesitated between the two.I ended up with the latter mainly because PSI is included in multiple cpp files, and the new classes don't need to be included as much.
As the static data partitioning work is under development and symbolized data access profiles may need helper functions and libraries, I think we can keep it this way and do refactors later where they fit. What do you think about this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good.