Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[AMDGPU] refactor WQM pass in preparation for WWM (NFCI)
Summary: Right now, the WQM pass conflates two different things when tracking the Needs of an instruction: 1. Needs can be StateWQM, which is propagated to other instructions, and means that this instruction (and everything it depends on) must be calculated in WQM. 2. Needs can be StateExact, which is not propagated to other instructions, and means that this instruction must not be calculated in WQM and WQM-ness must not be propagated past this instruction. This works now because there are only two different states, but in the future we want to be able to express things like "calculate this in WQM, but please disable WWM and don't propagate it" (to implement @llvm.amdgcn.set.inactive). In order to do this, we need to split the per-instruction Needs field in two: a new Needs field, which can only contain StateWQM (and in the future, StateWWM) and is propagated to sources, and a Disables field, which can also contain just StateWQM or nothing for now. We keep the per-block tracking the same for now, by translating Needs/Disables to the old representation with only StateWQM or StateExact. The other place that needs special handling is when we emit the state transitions. We could just translate back to the old representation there as well, which we almost do, but instead of 0 as a placeholder value for "any state," we explicitly or together all the states an instruction is allowed to be in. This lets us refactor the code in preparation for WWM, where we'll need to be able to handle things like "this instruction must be in Exact or WQM, but not WWM." Reviewers: arsenm, nhaehnle, tpr Subscribers: kzhuravl, wdng, yaxunl, dstuttard, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D35523 llvm-svn: 310086
- Loading branch information
Showing
1 changed file
with
77 additions
and
46 deletions.
There are no files selected for viewing
This file contains 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