[PATCH] D141393: [llvm][ir] Purge MD_prof custom accessors
Christian Ulmann via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jan 12 00:27:46 PST 2023
Dinistro added inline comments.
================
Comment at: llvm/lib/IR/Instructions.cpp:4606-4609
- if (ProfileData->getNumOperands() != SI.getNumSuccessors() + 1) {
- llvm_unreachable("number of prof branch_weights metadata operands does "
- "not correspond to number of succesors");
- }
----------------
paulkirth wrote:
> I don't think we do this check in ProfDatUtils, so we probably shouldn't remove it, should we? I know I've tripped this assert before when modifying some passes, so I think it's good one to keep.
I changed this back to have the `llvm_unreachable`. The newly added `getValidBranchWeightMDNode` could be used here but that would not cause an assertion violation.
================
Comment at: llvm/lib/IR/ProfDataUtils.cpp:46
// the minimum number of operands for MD_prof nodes with branch weights
-constexpr unsigned MinBWOps = 3;
+constexpr unsigned MinBWOps = 2;
----------------
davidxl wrote:
> paulkirth wrote:
> > This constant is used to check the validity of branch weight metadata. Changing this to 2 implies that a MD_prof node w/ only the "branch_weight" moniker and a single weight are valid. I don't think that's true, so I don't think this should change unless we change how MD_prof is laid out as a whole.
> agree. What the reason to change it to 2?
I changed this because calls can also have branch weights: https://llvm.org/docs/BranchWeightMetadata.html#callinst
It turns out that branch weights of calls different from other branch weights and can thus either way not be handled with the current state of this utility, so I reverted this part.
================
Comment at: llvm/lib/Transforms/Utils/Local.cpp:225
unsigned idx = i->getCaseIndex();
+ // TODO: Add overflow check.
Weights[0] += Weights[idx+1];
----------------
paulkirth wrote:
> Should we track this improvement w/ an issue? If you don't want to that's fine, but I always lose track of these TODOs unless I file something in a bug tracker and ref it from my code. Totally up to you though.
Good idea, I tracked this and another problem with the subsequent swap in here: https://github.com/llvm/llvm-project/issues/59956
================
Comment at: llvm/lib/Transforms/Utils/Local.cpp:315
SI->getDefaultDest());
- MDNode *MD = SI->getMetadata(LLVMContext::MD_prof);
- if (MD && MD->getNumOperands() == 3) {
- ConstantInt *SICase =
- mdconst::dyn_extract<ConstantInt>(MD->getOperand(2));
- ConstantInt *SIDef =
- mdconst::dyn_extract<ConstantInt>(MD->getOperand(1));
- assert(SICase && SIDef);
+ SmallVector<uint32_t> Weights;
+ if (extractBranchWeights(*SI, Weights) && Weights.size() == 2) {
----------------
paulkirth wrote:
> `uint64_t`, maybe? I can never remember what is guaranteed to run before we scale down to 32-bit weights, but the size should at least be the same between the weights vector and `DefWeight/CaseWeight`, right?
The `extractBranchWeights` function expects an `SmallVectorImp<uint32_t>`, so I now changed the `Weight` variables to `uint32_t` as well.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D141393/new/
https://reviews.llvm.org/D141393
More information about the llvm-commits
mailing list