Page MenuHomePhabricator

[llvm][ir] Purge MD_prof custom accessors

Authored by Dinistro on Jan 10 2023, 8:41 AM.



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:

Diff Detail

Event Timeline

Dinistro created this revision.Jan 10 2023, 8:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 10 2023, 8:41 AM
Dinistro requested review of this revision.Jan 10 2023, 8:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 10 2023, 8:42 AM

Added the reviewers of the previous commits to ProfDataUtils.cpp.

paulkirth requested changes to this revision.Jan 10 2023, 6:22 PM
paulkirth added a subscriber: paulkirth.

Thanks for picking this up. When I implemented ProfDataUtils there were still several things I wanted to address but havent' had sufficient bandwidth to pick up again. Looks like you've got most of the ones that I recall so far.

I left some feedback inline. Overall I think this is a good change. I have a few nits, and concerns that we may be missing some important checks, but most are pretty minor.

The one thing I'd say that definitely needs to change IMO is the addition of the SwitchInst to the True/False extractBranchWeights API. It seems error prone and wrong to use in almost all situations. But I'm not opposed to the change if there is a compelling reason, but I still don't see much benefit to it w/in this patch, except for one place in Local.cpp.


This is incorrect. This overload is specifically for branch/select instructions where the number of successors is 2. There is a more general version that uses weights vector for all instruction types, including switches.

If this API isn't needed anywhere/in the code base anymore, then it can be removed IMO, but this comment shouldn't change.


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.


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.


This is wrong. you can't include a switch here. The overload above takes a SmallVectorImpl is the only appropriate API when dealing with a switch, since it can have an arbitrary number of arms.

The assertion here is to prevent API misuse. If used on a switch, this will always return false, so I don't think thats the right choice here. You get some utility by being able to use this in more places, but I think this will be easy to introduce subtle bugs. For instance, if a switch happens to only have 2 arms this will work when it arguably shouldn't.

My preference would be that everything settle on the SmallVectorImpl API, since that can correctly handle all cases. It isn't' as ergonomic in some of the code uses though, IIRC.


Oh, this is a good change. The API use is much better at call sites.

Since the validation is basically done in ProfDataUtils, maybe rename this API to something more self descriptive?


nit: if we're changing the variable names, let's be consistent. I'd leave them as they were to limit the change, but if we're changing some, we should change them uniformly.


I think we discourage auto in cases like this, don't we?



Should we also provide this API in ProfDataUtils? It's a validity check for branch weight nodes, and we already encapsulate most of it ...


The overload will just get the MD node again anyway before calling the other API, so I'd suggest just using the MD node directly. Would you mind changing these and any others in this patch that use getBranchWeightMDNode prior to extractBranchWeights

This revision now requires changes to proceed.Jan 10 2023, 6:22 PM

great cleanup overall.


agree. What the reason to change it to 2?



Dinistro updated this revision to Diff 488130.Jan 11 2023, 2:56 AM
Dinistro marked 13 inline comments as done.

address reviewer comments

Dinistro updated this revision to Diff 488149.Jan 11 2023, 4:00 AM

Minor improvement


I'd consider inverting the logic between getValidBranchWeightMDNode() and hasValidBranchWeightMD()


I always forget the enumerate API exists ... what a massive improvement to readability.


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.


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?

Dinistro updated this revision to Diff 488503.Jan 12 2023, 12:22 AM
Dinistro marked 4 inline comments as done.

address additional comments

Dinistro added inline comments.Jan 12 2023, 12:27 AM

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.


I changed this because calls can also have branch weights:
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.


Good idea, I tracked this and another problem with the subsequent swap in here:


The extractBranchWeights function expects an SmallVectorImp<uint32_t>, so I now changed the Weight variables to uint32_t as well.

paulkirth accepted this revision.Jan 13 2023, 1:04 PM

This is LGTM from my perspective, as long as the 32-bit usage in Local.cpp is safe. Thanks for taking this up. I think it's a big improvement.


I think this is fine but we may want to double check that this only gets called after scaling down to 32-bit. Otherwise, maybe we should have a uint64_t version too, or make this a templated function in the .h, so the you can choose at the callsite. That can be a separate change though, as long as 32-bit is safe.

@davidxl do you know if this gets called after scaling down to 32-bit?

This revision is now accepted and ready to land.Jan 13 2023, 1:04 PM
davidxl accepted this revision.Jan 13 2023, 9:36 PM



IRPGO scales the count before setting the edge weights. Frontend based instrumentation does the same. Static branch weights have small values so they are fine too.

Thank you very much for the reviews. Could one of you commit this revision for me as I do not yet have commit access?

@Dinistro I can do that for you, but looking at your history, I'd say you should just request access. This is especially true, since I think you plan some follow up work w/ 64-bit weights, correct? Usually people get access w/in an hour or so, but w/in a day is the expectation.

But let me know, and I can land this for you. But just FYI, if I do so I'll be the Author unfortunately, but I will attribute you in the commit summary. For some reason the committer doesn't get emails from bots when breakages happen, and only the author does. So to avoid that I've just started doing it that way. It's very imperfect, and not my preference, but it's not easy to catch breakages otherwise.

This revision was automatically updated to reflect the committed changes.