2016-03-22 04:28:33 +08:00
|
|
|
//===-- SIWholeQuadMode.cpp - enter and suspend whole quad mode -----------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
/// \file
|
|
|
|
/// \brief This pass adds instructions to enable whole quad mode for pixel
|
|
|
|
/// shaders.
|
|
|
|
///
|
|
|
|
/// Whole quad mode is required for derivative computations, but it interferes
|
|
|
|
/// with shader side effects (stores and atomics). This pass is run on the
|
|
|
|
/// scheduled machine IR but before register coalescing, so that machine SSA is
|
|
|
|
/// available for analysis. It ensures that WQM is enabled when necessary, but
|
|
|
|
/// disabled around stores and atomics.
|
|
|
|
///
|
|
|
|
/// When necessary, this pass creates a function prolog
|
|
|
|
///
|
|
|
|
/// S_MOV_B64 LiveMask, EXEC
|
|
|
|
/// S_WQM_B64 EXEC, EXEC
|
|
|
|
///
|
|
|
|
/// to enter WQM at the top of the function and surrounds blocks of Exact
|
|
|
|
/// instructions by
|
|
|
|
///
|
|
|
|
/// S_AND_SAVEEXEC_B64 Tmp, LiveMask
|
|
|
|
/// ...
|
|
|
|
/// S_MOV_B64 EXEC, Tmp
|
|
|
|
///
|
|
|
|
/// In order to avoid excessive switching during sequences of Exact
|
|
|
|
/// instructions, the pass first analyzes which instructions must be run in WQM
|
|
|
|
/// (aka which instructions produce values that lead to derivative
|
|
|
|
/// computations).
|
|
|
|
///
|
|
|
|
/// Basic blocks are always exited in WQM as long as some successor needs WQM.
|
|
|
|
///
|
|
|
|
/// There is room for improvement given better control flow analysis:
|
|
|
|
///
|
|
|
|
/// (1) at the top level (outside of control flow statements, and as long as
|
|
|
|
/// kill hasn't been used), one SGPR can be saved by recovering WQM from
|
|
|
|
/// the LiveMask (this is implemented for the entry block).
|
|
|
|
///
|
|
|
|
/// (2) when entire regions (e.g. if-else blocks or entire loops) only
|
|
|
|
/// consist of exact and don't-care instructions, the switch only has to
|
|
|
|
/// be done at the entry and exit points rather than potentially in each
|
|
|
|
/// block of the region.
|
|
|
|
///
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "AMDGPU.h"
|
|
|
|
#include "AMDGPUSubtarget.h"
|
|
|
|
#include "SIInstrInfo.h"
|
|
|
|
#include "SIMachineFunctionInfo.h"
|
2016-12-10 06:06:55 +08:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
#include "llvm/ADT/PostOrderIterator.h"
|
2016-12-10 06:06:55 +08:00
|
|
|
#include "llvm/ADT/SmallVector.h"
|
|
|
|
#include "llvm/ADT/StringRef.h"
|
|
|
|
#include "llvm/CodeGen/LiveInterval.h"
|
|
|
|
#include "llvm/CodeGen/LiveIntervalAnalysis.h"
|
|
|
|
#include "llvm/CodeGen/MachineBasicBlock.h"
|
2016-03-22 04:28:33 +08:00
|
|
|
#include "llvm/CodeGen/MachineFunction.h"
|
|
|
|
#include "llvm/CodeGen/MachineFunctionPass.h"
|
2016-12-10 06:06:55 +08:00
|
|
|
#include "llvm/CodeGen/MachineInstr.h"
|
2016-03-22 04:28:33 +08:00
|
|
|
#include "llvm/CodeGen/MachineInstrBuilder.h"
|
2016-12-10 06:06:55 +08:00
|
|
|
#include "llvm/CodeGen/MachineOperand.h"
|
2016-03-22 04:28:33 +08:00
|
|
|
#include "llvm/CodeGen/MachineRegisterInfo.h"
|
2016-12-10 06:06:55 +08:00
|
|
|
#include "llvm/CodeGen/SlotIndexes.h"
|
|
|
|
#include "llvm/IR/CallingConv.h"
|
|
|
|
#include "llvm/IR/DebugLoc.h"
|
|
|
|
#include "llvm/MC/MCRegisterInfo.h"
|
|
|
|
#include "llvm/Pass.h"
|
|
|
|
#include "llvm/Support/Debug.h"
|
|
|
|
#include "llvm/Support/raw_ostream.h"
|
|
|
|
#include "llvm/Target/TargetRegisterInfo.h"
|
|
|
|
#include <cassert>
|
|
|
|
#include <vector>
|
2016-03-22 04:28:33 +08:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
#define DEBUG_TYPE "si-wqm"
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
enum {
|
|
|
|
StateWQM = 0x1,
|
|
|
|
StateExact = 0x2,
|
|
|
|
};
|
|
|
|
|
2016-09-03 20:26:38 +08:00
|
|
|
struct PrintState {
|
|
|
|
public:
|
|
|
|
int State;
|
2016-12-10 06:06:55 +08:00
|
|
|
|
|
|
|
explicit PrintState(int State) : State(State) {}
|
2016-09-03 20:26:38 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static raw_ostream &operator<<(raw_ostream &OS, const PrintState &PS) {
|
|
|
|
if (PS.State & StateWQM)
|
|
|
|
OS << "WQM";
|
|
|
|
if (PS.State & StateExact) {
|
|
|
|
if (PS.State & StateWQM)
|
|
|
|
OS << '|';
|
|
|
|
OS << "Exact";
|
|
|
|
}
|
|
|
|
|
|
|
|
return OS;
|
|
|
|
}
|
|
|
|
|
2016-03-22 04:28:33 +08:00
|
|
|
struct InstrInfo {
|
|
|
|
char Needs = 0;
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
char Disabled = 0;
|
2016-03-22 04:28:33 +08:00
|
|
|
char OutNeeds = 0;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct BlockInfo {
|
|
|
|
char Needs = 0;
|
|
|
|
char InNeeds = 0;
|
|
|
|
char OutNeeds = 0;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct WorkItem {
|
2016-07-13 13:55:15 +08:00
|
|
|
MachineBasicBlock *MBB = nullptr;
|
|
|
|
MachineInstr *MI = nullptr;
|
2016-03-22 04:28:33 +08:00
|
|
|
|
2016-12-10 06:06:55 +08:00
|
|
|
WorkItem() = default;
|
2016-07-13 13:55:15 +08:00
|
|
|
WorkItem(MachineBasicBlock *MBB) : MBB(MBB) {}
|
|
|
|
WorkItem(MachineInstr *MI) : MI(MI) {}
|
2016-03-22 04:28:33 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
class SIWholeQuadMode : public MachineFunctionPass {
|
|
|
|
private:
|
|
|
|
const SIInstrInfo *TII;
|
|
|
|
const SIRegisterInfo *TRI;
|
|
|
|
MachineRegisterInfo *MRI;
|
2016-08-03 03:17:37 +08:00
|
|
|
LiveIntervals *LIS;
|
2016-03-22 04:28:33 +08:00
|
|
|
|
|
|
|
DenseMap<const MachineInstr *, InstrInfo> Instructions;
|
2016-07-13 13:55:15 +08:00
|
|
|
DenseMap<MachineBasicBlock *, BlockInfo> Blocks;
|
2016-04-22 12:04:08 +08:00
|
|
|
SmallVector<MachineInstr *, 1> LiveMaskQueries;
|
[AMDGPU] Add an llvm.amdgcn.wqm intrinsic for WQM
Summary:
Previously, we assumed that certain types of instructions needed WQM in
pixel shaders, particularly DS instructions and image sampling
instructions. This was ok because with OpenGL, the assumption was
correct. But we want to start using DPP instructions for derivatives as
well as other things, so the assumption that we can infer whether to use
WQM based on the instruction won't continue to hold. This intrinsic lets
frontends like Mesa indicate what things need WQM based on their
knowledge of the API, rather than second-guessing them in the backend.
We need to keep around the old method of enabling WQM, but eventually we
should remove it once Mesa catches up. For now, this will let us use DPP
instructions for computing derivatives correctly.
Reviewers: arsenm, tpr, nhaehnle
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, llvm-commits, t-tye
Differential Revision: https://reviews.llvm.org/D35167
llvm-svn: 310085
2017-08-05 02:36:49 +08:00
|
|
|
SmallVector<MachineInstr *, 4> LowerToCopyInstrs;
|
2016-03-22 04:28:33 +08:00
|
|
|
|
2016-09-03 20:26:38 +08:00
|
|
|
void printInfo();
|
|
|
|
|
2016-08-03 03:17:37 +08:00
|
|
|
void markInstruction(MachineInstr &MI, char Flag,
|
|
|
|
std::vector<WorkItem> &Worklist);
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
void markInstructionUses(const MachineInstr &MI, char Flag,
|
|
|
|
std::vector<WorkItem> &Worklist);
|
2016-07-13 13:55:15 +08:00
|
|
|
char scanInstructions(MachineFunction &MF, std::vector<WorkItem> &Worklist);
|
|
|
|
void propagateInstruction(MachineInstr &MI, std::vector<WorkItem> &Worklist);
|
|
|
|
void propagateBlock(MachineBasicBlock &MBB, std::vector<WorkItem> &Worklist);
|
2016-04-22 12:04:08 +08:00
|
|
|
char analyzeFunction(MachineFunction &MF);
|
2016-03-22 04:28:33 +08:00
|
|
|
|
2016-09-13 00:25:20 +08:00
|
|
|
bool requiresCorrectState(const MachineInstr &MI) const;
|
|
|
|
|
|
|
|
MachineBasicBlock::iterator saveSCC(MachineBasicBlock &MBB,
|
|
|
|
MachineBasicBlock::iterator Before);
|
|
|
|
MachineBasicBlock::iterator
|
|
|
|
prepareInsertion(MachineBasicBlock &MBB, MachineBasicBlock::iterator First,
|
|
|
|
MachineBasicBlock::iterator Last, bool PreferLast,
|
|
|
|
bool SaveSCC);
|
2016-03-22 04:28:33 +08:00
|
|
|
void toExact(MachineBasicBlock &MBB, MachineBasicBlock::iterator Before,
|
|
|
|
unsigned SaveWQM, unsigned LiveMaskReg);
|
|
|
|
void toWQM(MachineBasicBlock &MBB, MachineBasicBlock::iterator Before,
|
|
|
|
unsigned SavedWQM);
|
|
|
|
void processBlock(MachineBasicBlock &MBB, unsigned LiveMaskReg, bool isEntry);
|
|
|
|
|
2016-04-22 12:04:08 +08:00
|
|
|
void lowerLiveMaskQueries(unsigned LiveMaskReg);
|
[AMDGPU] Add an llvm.amdgcn.wqm intrinsic for WQM
Summary:
Previously, we assumed that certain types of instructions needed WQM in
pixel shaders, particularly DS instructions and image sampling
instructions. This was ok because with OpenGL, the assumption was
correct. But we want to start using DPP instructions for derivatives as
well as other things, so the assumption that we can infer whether to use
WQM based on the instruction won't continue to hold. This intrinsic lets
frontends like Mesa indicate what things need WQM based on their
knowledge of the API, rather than second-guessing them in the backend.
We need to keep around the old method of enabling WQM, but eventually we
should remove it once Mesa catches up. For now, this will let us use DPP
instructions for computing derivatives correctly.
Reviewers: arsenm, tpr, nhaehnle
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, llvm-commits, t-tye
Differential Revision: https://reviews.llvm.org/D35167
llvm-svn: 310085
2017-08-05 02:36:49 +08:00
|
|
|
void lowerCopyInstrs();
|
2016-04-22 12:04:08 +08:00
|
|
|
|
2016-03-22 04:28:33 +08:00
|
|
|
public:
|
|
|
|
static char ID;
|
|
|
|
|
|
|
|
SIWholeQuadMode() :
|
|
|
|
MachineFunctionPass(ID) { }
|
|
|
|
|
|
|
|
bool runOnMachineFunction(MachineFunction &MF) override;
|
|
|
|
|
2016-10-01 10:56:57 +08:00
|
|
|
StringRef getPassName() const override { return "SI Whole Quad Mode"; }
|
2016-03-22 04:28:33 +08:00
|
|
|
|
|
|
|
void getAnalysisUsage(AnalysisUsage &AU) const override {
|
2016-08-03 03:17:37 +08:00
|
|
|
AU.addRequired<LiveIntervals>();
|
2016-03-22 04:28:33 +08:00
|
|
|
AU.setPreservesCFG();
|
|
|
|
MachineFunctionPass::getAnalysisUsage(AU);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2016-12-10 06:06:55 +08:00
|
|
|
} // end anonymous namespace
|
2016-03-22 04:28:33 +08:00
|
|
|
|
|
|
|
char SIWholeQuadMode::ID = 0;
|
|
|
|
|
2016-08-03 03:17:37 +08:00
|
|
|
INITIALIZE_PASS_BEGIN(SIWholeQuadMode, DEBUG_TYPE, "SI Whole Quad Mode", false,
|
|
|
|
false)
|
|
|
|
INITIALIZE_PASS_DEPENDENCY(LiveIntervals)
|
|
|
|
INITIALIZE_PASS_END(SIWholeQuadMode, DEBUG_TYPE, "SI Whole Quad Mode", false,
|
|
|
|
false)
|
2016-03-22 04:28:33 +08:00
|
|
|
|
|
|
|
char &llvm::SIWholeQuadModeID = SIWholeQuadMode::ID;
|
|
|
|
|
|
|
|
FunctionPass *llvm::createSIWholeQuadModePass() {
|
|
|
|
return new SIWholeQuadMode;
|
|
|
|
}
|
|
|
|
|
2016-09-03 20:26:38 +08:00
|
|
|
void SIWholeQuadMode::printInfo() {
|
|
|
|
for (const auto &BII : Blocks) {
|
|
|
|
dbgs() << "\nBB#" << BII.first->getNumber() << ":\n"
|
|
|
|
<< " InNeeds = " << PrintState(BII.second.InNeeds)
|
|
|
|
<< ", Needs = " << PrintState(BII.second.Needs)
|
|
|
|
<< ", OutNeeds = " << PrintState(BII.second.OutNeeds) << "\n\n";
|
|
|
|
|
|
|
|
for (const MachineInstr &MI : *BII.first) {
|
|
|
|
auto III = Instructions.find(&MI);
|
|
|
|
if (III == Instructions.end())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
dbgs() << " " << MI << " Needs = " << PrintState(III->second.Needs)
|
|
|
|
<< ", OutNeeds = " << PrintState(III->second.OutNeeds) << '\n';
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-08-03 03:17:37 +08:00
|
|
|
void SIWholeQuadMode::markInstruction(MachineInstr &MI, char Flag,
|
|
|
|
std::vector<WorkItem> &Worklist) {
|
|
|
|
InstrInfo &II = Instructions[&MI];
|
|
|
|
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
assert(Flag == StateWQM);
|
2016-08-03 03:17:37 +08:00
|
|
|
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
// Remove any disabled states from the flag. The user that required it gets
|
|
|
|
// an undefined value in the helper lanes. For example, this can happen if
|
|
|
|
// the result of an atomic is used by instruction that requires WQM, where
|
|
|
|
// ignoring the request for WQM is correct as per the relevant specs.
|
|
|
|
Flag &= ~II.Disabled;
|
|
|
|
|
|
|
|
// Ignore if the flag is already encompassed by the existing needs, or we
|
|
|
|
// just disabled everything.
|
|
|
|
if ((II.Needs & Flag) == Flag)
|
2016-08-03 03:17:37 +08:00
|
|
|
return;
|
|
|
|
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
II.Needs |= Flag;
|
2016-08-03 03:17:37 +08:00
|
|
|
Worklist.push_back(&MI);
|
|
|
|
}
|
|
|
|
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
/// Mark all instructions defining the uses in \p MI with \p Flag.
|
|
|
|
void SIWholeQuadMode::markInstructionUses(const MachineInstr &MI, char Flag,
|
|
|
|
std::vector<WorkItem> &Worklist) {
|
|
|
|
assert(Flag == StateWQM);
|
2016-09-03 20:26:38 +08:00
|
|
|
for (const MachineOperand &Use : MI.uses()) {
|
|
|
|
if (!Use.isReg() || !Use.isUse())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
unsigned Reg = Use.getReg();
|
|
|
|
|
|
|
|
// Handle physical registers that we need to track; this is mostly relevant
|
|
|
|
// for VCC, which can appear as the (implicit) input of a uniform branch,
|
|
|
|
// e.g. when a loop counter is stored in a VGPR.
|
|
|
|
if (!TargetRegisterInfo::isVirtualRegister(Reg)) {
|
|
|
|
if (Reg == AMDGPU::EXEC)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
for (MCRegUnitIterator RegUnit(Reg, TRI); RegUnit.isValid(); ++RegUnit) {
|
|
|
|
LiveRange &LR = LIS->getRegUnit(*RegUnit);
|
|
|
|
const VNInfo *Value = LR.Query(LIS->getInstructionIndex(MI)).valueIn();
|
|
|
|
if (!Value)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Since we're in machine SSA, we do not need to track physical
|
|
|
|
// registers across basic blocks.
|
|
|
|
if (Value->isPHIDef())
|
|
|
|
continue;
|
|
|
|
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
markInstruction(*LIS->getInstructionFromIndex(Value->def), Flag,
|
2016-09-03 20:26:38 +08:00
|
|
|
Worklist);
|
|
|
|
}
|
|
|
|
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (MachineInstr &DefMI : MRI->def_instructions(Use.getReg()))
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
markInstruction(DefMI, Flag, Worklist);
|
2016-09-03 20:26:38 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-03-22 04:28:33 +08:00
|
|
|
// Scan instructions to determine which ones require an Exact execmask and
|
|
|
|
// which ones seed WQM requirements.
|
2016-04-22 12:04:08 +08:00
|
|
|
char SIWholeQuadMode::scanInstructions(MachineFunction &MF,
|
2016-03-22 04:28:33 +08:00
|
|
|
std::vector<WorkItem> &Worklist) {
|
|
|
|
char GlobalFlags = 0;
|
AMDGPU: Add amdgpu-ps-wqm-outputs function attributes
Summary:
The presence of this attribute indicates that VGPR outputs should be computed
in whole quad mode. This will be used by Mesa for prolog pixel shaders, so
that derivatives can be taken of shader inputs computed by the prolog, fixing
a bug.
The generated code could certainly be improved: if a prolog pixel shader is
used (which isn't common in modern OpenGL - they're used for gl_Color, polygon
stipples, and forcing per-sample interpolation), Mesa will use this attribute
unconditionally, because it has to be conservative. So WQM may be used in the
prolog when it isn't really needed, and furthermore a silly back-and-forth
switch is likely to happen at the boundary between prolog and main shader
parts.
Fixing this is a bit involved: we'd first have to add a mechanism by which
LLVM writes the WQM-related input requirements to the main shader part binary,
and then Mesa specializes the prolog part accordingly. At that point, we may
as well just compile a monolithic shader...
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95130
Reviewers: arsenm, tstellarAMD, mareko
Subscribers: arsenm, llvm-commits, kzhuravl
Differential Revision: http://reviews.llvm.org/D20839
llvm-svn: 272063
2016-06-08 05:37:17 +08:00
|
|
|
bool WQMOutputs = MF.getFunction()->hasFnAttribute("amdgpu-ps-wqm-outputs");
|
2016-03-22 04:28:33 +08:00
|
|
|
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
// We need to visit the basic blocks in reverse post-order so that we visit
|
|
|
|
// defs before uses, in particular so that we don't accidentally mark an
|
|
|
|
// instruction as needing e.g. WQM before visiting it and realizing it needs
|
|
|
|
// WQM disabled.
|
|
|
|
ReversePostOrderTraversal<MachineFunction *> RPOT(&MF);
|
|
|
|
for (auto BI = RPOT.begin(), BE = RPOT.end(); BI != BE; ++BI) {
|
|
|
|
MachineBasicBlock &MBB = **BI;
|
|
|
|
BlockInfo &BBI = Blocks[&MBB];
|
2016-03-22 04:28:33 +08:00
|
|
|
|
|
|
|
for (auto II = MBB.begin(), IE = MBB.end(); II != IE; ++II) {
|
2016-04-22 12:04:08 +08:00
|
|
|
MachineInstr &MI = *II;
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
InstrInfo &III = Instructions[&MI];
|
2016-03-22 04:28:33 +08:00
|
|
|
unsigned Opcode = MI.getOpcode();
|
AMDGPU: Add amdgpu-ps-wqm-outputs function attributes
Summary:
The presence of this attribute indicates that VGPR outputs should be computed
in whole quad mode. This will be used by Mesa for prolog pixel shaders, so
that derivatives can be taken of shader inputs computed by the prolog, fixing
a bug.
The generated code could certainly be improved: if a prolog pixel shader is
used (which isn't common in modern OpenGL - they're used for gl_Color, polygon
stipples, and forcing per-sample interpolation), Mesa will use this attribute
unconditionally, because it has to be conservative. So WQM may be used in the
prolog when it isn't really needed, and furthermore a silly back-and-forth
switch is likely to happen at the boundary between prolog and main shader
parts.
Fixing this is a bit involved: we'd first have to add a mechanism by which
LLVM writes the WQM-related input requirements to the main shader part binary,
and then Mesa specializes the prolog part accordingly. At that point, we may
as well just compile a monolithic shader...
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95130
Reviewers: arsenm, tstellarAMD, mareko
Subscribers: arsenm, llvm-commits, kzhuravl
Differential Revision: http://reviews.llvm.org/D20839
llvm-svn: 272063
2016-06-08 05:37:17 +08:00
|
|
|
char Flags = 0;
|
2016-03-22 04:28:33 +08:00
|
|
|
|
2016-09-03 20:26:38 +08:00
|
|
|
if (TII->isDS(Opcode)) {
|
2016-03-22 04:28:33 +08:00
|
|
|
Flags = StateWQM;
|
2016-09-03 20:26:38 +08:00
|
|
|
} else if (TII->isWQM(Opcode)) {
|
|
|
|
// Sampling instructions don't need to produce results for all pixels
|
|
|
|
// in a quad, they just require all inputs of a quad to have been
|
|
|
|
// computed for derivatives.
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
markInstructionUses(MI, StateWQM, Worklist);
|
2016-09-03 20:26:38 +08:00
|
|
|
GlobalFlags |= StateWQM;
|
|
|
|
continue;
|
[AMDGPU] Add an llvm.amdgcn.wqm intrinsic for WQM
Summary:
Previously, we assumed that certain types of instructions needed WQM in
pixel shaders, particularly DS instructions and image sampling
instructions. This was ok because with OpenGL, the assumption was
correct. But we want to start using DPP instructions for derivatives as
well as other things, so the assumption that we can infer whether to use
WQM based on the instruction won't continue to hold. This intrinsic lets
frontends like Mesa indicate what things need WQM based on their
knowledge of the API, rather than second-guessing them in the backend.
We need to keep around the old method of enabling WQM, but eventually we
should remove it once Mesa catches up. For now, this will let us use DPP
instructions for computing derivatives correctly.
Reviewers: arsenm, tpr, nhaehnle
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, llvm-commits, t-tye
Differential Revision: https://reviews.llvm.org/D35167
llvm-svn: 310085
2017-08-05 02:36:49 +08:00
|
|
|
} else if (Opcode == AMDGPU::WQM) {
|
|
|
|
// The WQM intrinsic requires its output to have all the helper lanes
|
|
|
|
// correct, so we need it to be in WQM.
|
|
|
|
Flags = StateWQM;
|
|
|
|
LowerToCopyInstrs.push_back(&MI);
|
2016-08-03 03:31:14 +08:00
|
|
|
} else if (TII->isDisableWQM(MI)) {
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
BBI.Needs |= StateExact;
|
|
|
|
if (!(BBI.InNeeds & StateExact)) {
|
|
|
|
BBI.InNeeds |= StateExact;
|
|
|
|
Worklist.push_back(&MBB);
|
|
|
|
}
|
|
|
|
GlobalFlags |= StateExact;
|
|
|
|
III.Disabled = StateWQM;
|
|
|
|
continue;
|
2016-03-22 04:28:33 +08:00
|
|
|
} else {
|
2016-09-03 20:26:38 +08:00
|
|
|
if (Opcode == AMDGPU::SI_PS_LIVE) {
|
2016-04-22 12:04:08 +08:00
|
|
|
LiveMaskQueries.push_back(&MI);
|
AMDGPU: Add amdgpu-ps-wqm-outputs function attributes
Summary:
The presence of this attribute indicates that VGPR outputs should be computed
in whole quad mode. This will be used by Mesa for prolog pixel shaders, so
that derivatives can be taken of shader inputs computed by the prolog, fixing
a bug.
The generated code could certainly be improved: if a prolog pixel shader is
used (which isn't common in modern OpenGL - they're used for gl_Color, polygon
stipples, and forcing per-sample interpolation), Mesa will use this attribute
unconditionally, because it has to be conservative. So WQM may be used in the
prolog when it isn't really needed, and furthermore a silly back-and-forth
switch is likely to happen at the boundary between prolog and main shader
parts.
Fixing this is a bit involved: we'd first have to add a mechanism by which
LLVM writes the WQM-related input requirements to the main shader part binary,
and then Mesa specializes the prolog part accordingly. At that point, we may
as well just compile a monolithic shader...
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95130
Reviewers: arsenm, tstellarAMD, mareko
Subscribers: arsenm, llvm-commits, kzhuravl
Differential Revision: http://reviews.llvm.org/D20839
llvm-svn: 272063
2016-06-08 05:37:17 +08:00
|
|
|
} else if (WQMOutputs) {
|
|
|
|
// The function is in machine SSA form, which means that physical
|
|
|
|
// VGPRs correspond to shader inputs and outputs. Inputs are
|
|
|
|
// only used, outputs are only defined.
|
|
|
|
for (const MachineOperand &MO : MI.defs()) {
|
|
|
|
if (!MO.isReg())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
unsigned Reg = MO.getReg();
|
|
|
|
|
|
|
|
if (!TRI->isVirtualRegister(Reg) &&
|
|
|
|
TRI->hasVGPRs(TRI->getPhysRegClass(Reg))) {
|
|
|
|
Flags = StateWQM;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2016-04-22 12:04:08 +08:00
|
|
|
}
|
|
|
|
|
AMDGPU: Add amdgpu-ps-wqm-outputs function attributes
Summary:
The presence of this attribute indicates that VGPR outputs should be computed
in whole quad mode. This will be used by Mesa for prolog pixel shaders, so
that derivatives can be taken of shader inputs computed by the prolog, fixing
a bug.
The generated code could certainly be improved: if a prolog pixel shader is
used (which isn't common in modern OpenGL - they're used for gl_Color, polygon
stipples, and forcing per-sample interpolation), Mesa will use this attribute
unconditionally, because it has to be conservative. So WQM may be used in the
prolog when it isn't really needed, and furthermore a silly back-and-forth
switch is likely to happen at the boundary between prolog and main shader
parts.
Fixing this is a bit involved: we'd first have to add a mechanism by which
LLVM writes the WQM-related input requirements to the main shader part binary,
and then Mesa specializes the prolog part accordingly. At that point, we may
as well just compile a monolithic shader...
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95130
Reviewers: arsenm, tstellarAMD, mareko
Subscribers: arsenm, llvm-commits, kzhuravl
Differential Revision: http://reviews.llvm.org/D20839
llvm-svn: 272063
2016-06-08 05:37:17 +08:00
|
|
|
if (!Flags)
|
|
|
|
continue;
|
2016-03-22 04:28:33 +08:00
|
|
|
}
|
|
|
|
|
2016-08-03 03:17:37 +08:00
|
|
|
markInstruction(MI, Flags, Worklist);
|
2016-03-22 04:28:33 +08:00
|
|
|
GlobalFlags |= Flags;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return GlobalFlags;
|
|
|
|
}
|
|
|
|
|
2016-07-13 13:55:15 +08:00
|
|
|
void SIWholeQuadMode::propagateInstruction(MachineInstr &MI,
|
2016-03-22 04:28:33 +08:00
|
|
|
std::vector<WorkItem>& Worklist) {
|
2016-07-13 13:55:15 +08:00
|
|
|
MachineBasicBlock *MBB = MI.getParent();
|
2016-03-22 06:54:02 +08:00
|
|
|
InstrInfo II = Instructions[&MI]; // take a copy to prevent dangling references
|
2016-07-13 13:55:15 +08:00
|
|
|
BlockInfo &BI = Blocks[MBB];
|
2016-03-22 04:28:33 +08:00
|
|
|
|
2016-08-03 03:31:14 +08:00
|
|
|
// Control flow-type instructions and stores to temporary memory that are
|
|
|
|
// followed by WQM computations must themselves be in WQM.
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
if ((II.OutNeeds & StateWQM) && !(II.Disabled & StateWQM) &&
|
2016-08-03 03:31:14 +08:00
|
|
|
(MI.isTerminator() || (TII->usesVM_CNT(MI) && MI.mayStore()))) {
|
2016-03-22 06:54:02 +08:00
|
|
|
Instructions[&MI].Needs = StateWQM;
|
2016-03-22 04:28:33 +08:00
|
|
|
II.Needs = StateWQM;
|
2016-03-22 06:54:02 +08:00
|
|
|
}
|
2016-03-22 04:28:33 +08:00
|
|
|
|
|
|
|
// Propagate to block level
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
if (II.Needs & StateWQM) {
|
|
|
|
BI.Needs |= StateWQM;
|
|
|
|
if (!(BI.InNeeds & StateWQM)) {
|
|
|
|
BI.InNeeds |= StateWQM;
|
|
|
|
Worklist.push_back(MBB);
|
|
|
|
}
|
2016-03-22 04:28:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Propagate backwards within block
|
2016-07-13 13:55:15 +08:00
|
|
|
if (MachineInstr *PrevMI = MI.getPrevNode()) {
|
2016-03-22 04:28:33 +08:00
|
|
|
char InNeeds = II.Needs | II.OutNeeds;
|
|
|
|
if (!PrevMI->isPHI()) {
|
|
|
|
InstrInfo &PrevII = Instructions[PrevMI];
|
|
|
|
if ((PrevII.OutNeeds | InNeeds) != PrevII.OutNeeds) {
|
|
|
|
PrevII.OutNeeds |= InNeeds;
|
|
|
|
Worklist.push_back(PrevMI);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Propagate WQM flag to instruction inputs
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
assert(!(II.Needs & StateExact));
|
2016-08-03 03:17:37 +08:00
|
|
|
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
if (II.Needs != 0)
|
|
|
|
markInstructionUses(MI, II.Needs, Worklist);
|
2016-03-22 04:28:33 +08:00
|
|
|
}
|
|
|
|
|
2016-07-13 13:55:15 +08:00
|
|
|
void SIWholeQuadMode::propagateBlock(MachineBasicBlock &MBB,
|
2016-03-22 04:28:33 +08:00
|
|
|
std::vector<WorkItem>& Worklist) {
|
2016-07-13 13:55:15 +08:00
|
|
|
BlockInfo BI = Blocks[&MBB]; // Make a copy to prevent dangling references.
|
2016-03-22 04:28:33 +08:00
|
|
|
|
|
|
|
// Propagate through instructions
|
|
|
|
if (!MBB.empty()) {
|
2016-07-13 13:55:15 +08:00
|
|
|
MachineInstr *LastMI = &*MBB.rbegin();
|
2016-03-22 04:28:33 +08:00
|
|
|
InstrInfo &LastII = Instructions[LastMI];
|
|
|
|
if ((LastII.OutNeeds | BI.OutNeeds) != LastII.OutNeeds) {
|
|
|
|
LastII.OutNeeds |= BI.OutNeeds;
|
|
|
|
Worklist.push_back(LastMI);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Predecessor blocks must provide for our WQM/Exact needs.
|
2016-07-13 13:55:15 +08:00
|
|
|
for (MachineBasicBlock *Pred : MBB.predecessors()) {
|
2016-03-22 04:28:33 +08:00
|
|
|
BlockInfo &PredBI = Blocks[Pred];
|
|
|
|
if ((PredBI.OutNeeds | BI.InNeeds) == PredBI.OutNeeds)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
PredBI.OutNeeds |= BI.InNeeds;
|
|
|
|
PredBI.InNeeds |= BI.InNeeds;
|
|
|
|
Worklist.push_back(Pred);
|
|
|
|
}
|
|
|
|
|
2016-07-13 13:55:15 +08:00
|
|
|
// All successors must be prepared to accept the same set of WQM/Exact data.
|
|
|
|
for (MachineBasicBlock *Succ : MBB.successors()) {
|
2016-03-22 04:28:33 +08:00
|
|
|
BlockInfo &SuccBI = Blocks[Succ];
|
|
|
|
if ((SuccBI.InNeeds | BI.OutNeeds) == SuccBI.InNeeds)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
SuccBI.InNeeds |= BI.OutNeeds;
|
|
|
|
Worklist.push_back(Succ);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-04-22 12:04:08 +08:00
|
|
|
char SIWholeQuadMode::analyzeFunction(MachineFunction &MF) {
|
2016-03-22 04:28:33 +08:00
|
|
|
std::vector<WorkItem> Worklist;
|
|
|
|
char GlobalFlags = scanInstructions(MF, Worklist);
|
|
|
|
|
|
|
|
while (!Worklist.empty()) {
|
|
|
|
WorkItem WI = Worklist.back();
|
|
|
|
Worklist.pop_back();
|
|
|
|
|
|
|
|
if (WI.MI)
|
|
|
|
propagateInstruction(*WI.MI, Worklist);
|
|
|
|
else
|
|
|
|
propagateBlock(*WI.MBB, Worklist);
|
|
|
|
}
|
|
|
|
|
|
|
|
return GlobalFlags;
|
|
|
|
}
|
|
|
|
|
2016-09-13 00:25:20 +08:00
|
|
|
/// Whether \p MI really requires the exec state computed during analysis.
|
|
|
|
///
|
|
|
|
/// Scalar instructions must occasionally be marked WQM for correct propagation
|
|
|
|
/// (e.g. thread masks leading up to branches), but when it comes to actual
|
|
|
|
/// execution, they don't care about EXEC.
|
|
|
|
bool SIWholeQuadMode::requiresCorrectState(const MachineInstr &MI) const {
|
|
|
|
if (MI.isTerminator())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// Skip instructions that are not affected by EXEC
|
|
|
|
if (TII->isScalarUnit(MI))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Generic instructions such as COPY will either disappear by register
|
|
|
|
// coalescing or be lowered to SALU or VALU instructions.
|
|
|
|
if (MI.isTransient()) {
|
|
|
|
if (MI.getNumExplicitOperands() >= 1) {
|
|
|
|
const MachineOperand &Op = MI.getOperand(0);
|
|
|
|
if (Op.isReg()) {
|
|
|
|
if (TRI->isSGPRReg(*MRI, Op.getReg())) {
|
|
|
|
// SGPR instructions are not affected by EXEC
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
MachineBasicBlock::iterator
|
|
|
|
SIWholeQuadMode::saveSCC(MachineBasicBlock &MBB,
|
|
|
|
MachineBasicBlock::iterator Before) {
|
2016-11-26 01:37:09 +08:00
|
|
|
unsigned SaveReg = MRI->createVirtualRegister(&AMDGPU::SReg_32_XM0RegClass);
|
2016-09-13 00:25:20 +08:00
|
|
|
|
|
|
|
MachineInstr *Save =
|
|
|
|
BuildMI(MBB, Before, DebugLoc(), TII->get(AMDGPU::COPY), SaveReg)
|
|
|
|
.addReg(AMDGPU::SCC);
|
|
|
|
MachineInstr *Restore =
|
|
|
|
BuildMI(MBB, Before, DebugLoc(), TII->get(AMDGPU::COPY), AMDGPU::SCC)
|
|
|
|
.addReg(SaveReg);
|
|
|
|
|
|
|
|
LIS->InsertMachineInstrInMaps(*Save);
|
|
|
|
LIS->InsertMachineInstrInMaps(*Restore);
|
|
|
|
LIS->createAndComputeVirtRegInterval(SaveReg);
|
|
|
|
|
|
|
|
return Restore;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Return an iterator in the (inclusive) range [First, Last] at which
|
|
|
|
// instructions can be safely inserted, keeping in mind that some of the
|
|
|
|
// instructions we want to add necessarily clobber SCC.
|
|
|
|
MachineBasicBlock::iterator SIWholeQuadMode::prepareInsertion(
|
|
|
|
MachineBasicBlock &MBB, MachineBasicBlock::iterator First,
|
|
|
|
MachineBasicBlock::iterator Last, bool PreferLast, bool SaveSCC) {
|
|
|
|
if (!SaveSCC)
|
|
|
|
return PreferLast ? Last : First;
|
|
|
|
|
|
|
|
LiveRange &LR = LIS->getRegUnit(*MCRegUnitIterator(AMDGPU::SCC, TRI));
|
|
|
|
auto MBBE = MBB.end();
|
|
|
|
SlotIndex FirstIdx = First != MBBE ? LIS->getInstructionIndex(*First)
|
|
|
|
: LIS->getMBBEndIdx(&MBB);
|
|
|
|
SlotIndex LastIdx =
|
|
|
|
Last != MBBE ? LIS->getInstructionIndex(*Last) : LIS->getMBBEndIdx(&MBB);
|
|
|
|
SlotIndex Idx = PreferLast ? LastIdx : FirstIdx;
|
|
|
|
const LiveRange::Segment *S;
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
S = LR.getSegmentContaining(Idx);
|
|
|
|
if (!S)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (PreferLast) {
|
|
|
|
SlotIndex Next = S->start.getBaseIndex();
|
|
|
|
if (Next < FirstIdx)
|
|
|
|
break;
|
|
|
|
Idx = Next;
|
|
|
|
} else {
|
|
|
|
SlotIndex Next = S->end.getNextIndex().getBaseIndex();
|
|
|
|
if (Next > LastIdx)
|
|
|
|
break;
|
|
|
|
Idx = Next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
MachineBasicBlock::iterator MBBI;
|
|
|
|
|
|
|
|
if (MachineInstr *MI = LIS->getInstructionFromIndex(Idx))
|
|
|
|
MBBI = MI;
|
|
|
|
else {
|
|
|
|
assert(Idx == LIS->getMBBEndIdx(&MBB));
|
|
|
|
MBBI = MBB.end();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (S)
|
|
|
|
MBBI = saveSCC(MBB, MBBI);
|
|
|
|
|
|
|
|
return MBBI;
|
|
|
|
}
|
|
|
|
|
2016-03-22 04:28:33 +08:00
|
|
|
void SIWholeQuadMode::toExact(MachineBasicBlock &MBB,
|
|
|
|
MachineBasicBlock::iterator Before,
|
2016-03-22 04:39:24 +08:00
|
|
|
unsigned SaveWQM, unsigned LiveMaskReg) {
|
2016-09-13 00:25:20 +08:00
|
|
|
MachineInstr *MI;
|
|
|
|
|
2016-03-22 04:28:33 +08:00
|
|
|
if (SaveWQM) {
|
2016-09-13 00:25:20 +08:00
|
|
|
MI = BuildMI(MBB, Before, DebugLoc(), TII->get(AMDGPU::S_AND_SAVEEXEC_B64),
|
|
|
|
SaveWQM)
|
|
|
|
.addReg(LiveMaskReg);
|
2016-03-22 04:28:33 +08:00
|
|
|
} else {
|
2016-09-13 00:25:20 +08:00
|
|
|
MI = BuildMI(MBB, Before, DebugLoc(), TII->get(AMDGPU::S_AND_B64),
|
|
|
|
AMDGPU::EXEC)
|
|
|
|
.addReg(AMDGPU::EXEC)
|
|
|
|
.addReg(LiveMaskReg);
|
2016-03-22 04:28:33 +08:00
|
|
|
}
|
2016-09-13 00:25:20 +08:00
|
|
|
|
|
|
|
LIS->InsertMachineInstrInMaps(*MI);
|
2016-03-22 04:28:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void SIWholeQuadMode::toWQM(MachineBasicBlock &MBB,
|
|
|
|
MachineBasicBlock::iterator Before,
|
2016-03-22 04:39:24 +08:00
|
|
|
unsigned SavedWQM) {
|
2016-09-13 00:25:20 +08:00
|
|
|
MachineInstr *MI;
|
|
|
|
|
2016-03-22 04:28:33 +08:00
|
|
|
if (SavedWQM) {
|
2016-09-13 00:25:20 +08:00
|
|
|
MI = BuildMI(MBB, Before, DebugLoc(), TII->get(AMDGPU::COPY), AMDGPU::EXEC)
|
|
|
|
.addReg(SavedWQM);
|
2016-03-22 04:28:33 +08:00
|
|
|
} else {
|
2016-09-13 00:25:20 +08:00
|
|
|
MI = BuildMI(MBB, Before, DebugLoc(), TII->get(AMDGPU::S_WQM_B64),
|
|
|
|
AMDGPU::EXEC)
|
|
|
|
.addReg(AMDGPU::EXEC);
|
2016-03-22 04:28:33 +08:00
|
|
|
}
|
2016-09-13 00:25:20 +08:00
|
|
|
|
|
|
|
LIS->InsertMachineInstrInMaps(*MI);
|
2016-03-22 04:28:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void SIWholeQuadMode::processBlock(MachineBasicBlock &MBB, unsigned LiveMaskReg,
|
|
|
|
bool isEntry) {
|
|
|
|
auto BII = Blocks.find(&MBB);
|
|
|
|
if (BII == Blocks.end())
|
|
|
|
return;
|
|
|
|
|
|
|
|
const BlockInfo &BI = BII->second;
|
|
|
|
|
|
|
|
if (!(BI.InNeeds & StateWQM))
|
|
|
|
return;
|
|
|
|
|
|
|
|
// This is a non-entry block that is WQM throughout, so no need to do
|
|
|
|
// anything.
|
|
|
|
if (!isEntry && !(BI.Needs & StateExact) && BI.OutNeeds != StateExact)
|
|
|
|
return;
|
|
|
|
|
2016-09-03 20:26:38 +08:00
|
|
|
DEBUG(dbgs() << "\nProcessing block BB#" << MBB.getNumber() << ":\n");
|
|
|
|
|
2016-03-22 04:28:33 +08:00
|
|
|
unsigned SavedWQMReg = 0;
|
|
|
|
bool WQMFromExec = isEntry;
|
|
|
|
char State = isEntry ? StateExact : StateWQM;
|
|
|
|
|
|
|
|
auto II = MBB.getFirstNonPHI(), IE = MBB.end();
|
2016-09-13 00:25:20 +08:00
|
|
|
if (isEntry)
|
|
|
|
++II; // Skip the instruction that saves LiveMask
|
2016-03-22 04:28:33 +08:00
|
|
|
|
2016-09-13 00:25:20 +08:00
|
|
|
MachineBasicBlock::iterator First = IE;
|
|
|
|
for (;;) {
|
|
|
|
MachineBasicBlock::iterator Next = II;
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
char Needs = StateExact | StateWQM;
|
2016-09-13 00:25:20 +08:00
|
|
|
char OutNeeds = 0;
|
2016-03-22 04:28:33 +08:00
|
|
|
|
2016-09-13 00:25:20 +08:00
|
|
|
if (First == IE)
|
|
|
|
First = II;
|
|
|
|
|
|
|
|
if (II != IE) {
|
|
|
|
MachineInstr &MI = *II;
|
|
|
|
|
|
|
|
if (requiresCorrectState(MI)) {
|
|
|
|
auto III = Instructions.find(&MI);
|
|
|
|
if (III != Instructions.end()) {
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
if (III->second.Needs & StateWQM)
|
|
|
|
Needs = StateWQM;
|
|
|
|
else
|
|
|
|
Needs &= ~III->second.Disabled;
|
2016-09-13 00:25:20 +08:00
|
|
|
OutNeeds = III->second.OutNeeds;
|
2016-03-22 04:28:33 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
if (MI.isTerminator() && OutNeeds == StateExact)
|
2016-09-13 00:25:20 +08:00
|
|
|
Needs = StateExact;
|
|
|
|
|
|
|
|
if (MI.getOpcode() == AMDGPU::SI_ELSE && BI.OutNeeds == StateExact)
|
|
|
|
MI.getOperand(3).setImm(1);
|
|
|
|
|
|
|
|
++Next;
|
|
|
|
} else {
|
|
|
|
// End of basic block
|
|
|
|
if (BI.OutNeeds & StateWQM)
|
|
|
|
Needs = StateWQM;
|
|
|
|
else if (BI.OutNeeds == StateExact)
|
|
|
|
Needs = StateExact;
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
else
|
|
|
|
Needs = StateWQM | StateExact;
|
2016-03-22 04:28:33 +08:00
|
|
|
}
|
|
|
|
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
if (!(Needs & State)) {
|
|
|
|
MachineBasicBlock::iterator Before =
|
|
|
|
prepareInsertion(MBB, First, II, Needs == StateWQM,
|
|
|
|
Needs == StateExact || WQMFromExec);
|
2016-09-03 20:26:38 +08:00
|
|
|
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
if (Needs == StateExact) {
|
|
|
|
if (!WQMFromExec && (OutNeeds & StateWQM))
|
|
|
|
SavedWQMReg = MRI->createVirtualRegister(&AMDGPU::SReg_64RegClass);
|
2016-03-22 04:28:33 +08:00
|
|
|
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
toExact(MBB, Before, SavedWQMReg, LiveMaskReg);
|
|
|
|
State = StateExact;
|
|
|
|
} else {
|
|
|
|
assert(Needs == StateWQM);
|
|
|
|
assert(WQMFromExec == (SavedWQMReg == 0));
|
2016-03-22 04:28:33 +08:00
|
|
|
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
toWQM(MBB, Before, SavedWQMReg);
|
2016-09-13 00:25:20 +08:00
|
|
|
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
if (SavedWQMReg) {
|
|
|
|
LIS->createAndComputeVirtRegInterval(SavedWQMReg);
|
|
|
|
SavedWQMReg = 0;
|
2016-09-13 00:25:20 +08:00
|
|
|
}
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
State = StateWQM;
|
2016-03-22 04:28:33 +08:00
|
|
|
}
|
|
|
|
|
2016-09-13 00:25:20 +08:00
|
|
|
First = IE;
|
2016-03-22 04:28:33 +08:00
|
|
|
}
|
AMDGPU: add execfix flag to SI_ELSE
Summary:
SI_ELSE is lowered into two parts:
s_or_saveexec_b64 dst, src (at the start of the basic block)
s_xor_b64 exec, exec, dst (at the end of the basic block)
The idea is that dst contains the exec mask of the preceding IF block. It can
happen that SIWholeQuadMode decides to switch from WQM to Exact mode inside
the basic block that contains SI_ELSE, in which case it introduces an instruction
s_and_b64 exec, exec, s[...]
which masks out bits that can correspond to both the IF and the ELSE paths.
So the resulting sequence must be:
s_or_savexec_b64 dst, src
s_and_b64 exec, exec, s[...] <-- added by SIWholeQuadMode
s_and_b64 dst, dst, exec <-- added by SILowerControlFlow
s_xor_b64 exec, exec, dst
Whether to add the additional s_and_b64 dst, dst, exec is currently determined
via the ExecModified tracking. With this change, it is instead determined by
an additional flag on SI_ELSE which is set by SIWholeQuadMode.
Finally: It also occured to me that an alternative approach for the long run
is for SILowerControlFlow to unconditionally emit
s_or_saveexec_b64 dst, src
...
s_and_b64 dst, dst, exec
s_xor_b64 exec, exec, dst
and have a pass that detects and cleans up the "redundant AND with exec"
pattern where possible. This could be useful anyway, because we also add
instructions
s_and_b64 vcc, exec, vcc
before s_cbranch_scc (in moveToALU), and those are often redundant. I have
some pending changes to how KILL is lowered that could also benefit from
such a cleanup pass.
In any case, this current patch could help in the short term with the whole
ExecModified business.
Reviewers: tstellarAMD, arsenm
Subscribers: arsenm, llvm-commits, kzhuravl
Differential Revision: https://reviews.llvm.org/D22846
llvm-svn: 276972
2016-07-28 19:39:24 +08:00
|
|
|
|
[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
2017-08-05 02:36:50 +08:00
|
|
|
if (Needs != (StateExact | StateWQM))
|
|
|
|
First = IE;
|
|
|
|
|
2016-09-13 00:25:20 +08:00
|
|
|
if (II == IE)
|
|
|
|
break;
|
|
|
|
II = Next;
|
2016-03-22 04:28:33 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-04-22 12:04:08 +08:00
|
|
|
void SIWholeQuadMode::lowerLiveMaskQueries(unsigned LiveMaskReg) {
|
|
|
|
for (MachineInstr *MI : LiveMaskQueries) {
|
2016-07-13 13:55:15 +08:00
|
|
|
const DebugLoc &DL = MI->getDebugLoc();
|
2016-04-22 12:04:08 +08:00
|
|
|
unsigned Dest = MI->getOperand(0).getReg();
|
2016-09-13 00:25:20 +08:00
|
|
|
MachineInstr *Copy =
|
|
|
|
BuildMI(*MI->getParent(), MI, DL, TII->get(AMDGPU::COPY), Dest)
|
|
|
|
.addReg(LiveMaskReg);
|
|
|
|
|
|
|
|
LIS->ReplaceMachineInstrInMaps(*MI, *Copy);
|
2016-04-22 12:04:08 +08:00
|
|
|
MI->eraseFromParent();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[AMDGPU] Add an llvm.amdgcn.wqm intrinsic for WQM
Summary:
Previously, we assumed that certain types of instructions needed WQM in
pixel shaders, particularly DS instructions and image sampling
instructions. This was ok because with OpenGL, the assumption was
correct. But we want to start using DPP instructions for derivatives as
well as other things, so the assumption that we can infer whether to use
WQM based on the instruction won't continue to hold. This intrinsic lets
frontends like Mesa indicate what things need WQM based on their
knowledge of the API, rather than second-guessing them in the backend.
We need to keep around the old method of enabling WQM, but eventually we
should remove it once Mesa catches up. For now, this will let us use DPP
instructions for computing derivatives correctly.
Reviewers: arsenm, tpr, nhaehnle
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, llvm-commits, t-tye
Differential Revision: https://reviews.llvm.org/D35167
llvm-svn: 310085
2017-08-05 02:36:49 +08:00
|
|
|
void SIWholeQuadMode::lowerCopyInstrs() {
|
|
|
|
for (MachineInstr *MI : LowerToCopyInstrs)
|
|
|
|
MI->setDesc(TII->get(AMDGPU::COPY));
|
|
|
|
}
|
|
|
|
|
2016-03-22 04:28:33 +08:00
|
|
|
bool SIWholeQuadMode::runOnMachineFunction(MachineFunction &MF) {
|
2016-04-07 03:40:20 +08:00
|
|
|
if (MF.getFunction()->getCallingConv() != CallingConv::AMDGPU_PS)
|
2016-03-22 04:28:33 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
Instructions.clear();
|
|
|
|
Blocks.clear();
|
2016-04-22 12:04:08 +08:00
|
|
|
LiveMaskQueries.clear();
|
[AMDGPU] Add an llvm.amdgcn.wqm intrinsic for WQM
Summary:
Previously, we assumed that certain types of instructions needed WQM in
pixel shaders, particularly DS instructions and image sampling
instructions. This was ok because with OpenGL, the assumption was
correct. But we want to start using DPP instructions for derivatives as
well as other things, so the assumption that we can infer whether to use
WQM based on the instruction won't continue to hold. This intrinsic lets
frontends like Mesa indicate what things need WQM based on their
knowledge of the API, rather than second-guessing them in the backend.
We need to keep around the old method of enabling WQM, but eventually we
should remove it once Mesa catches up. For now, this will let us use DPP
instructions for computing derivatives correctly.
Reviewers: arsenm, tpr, nhaehnle
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, llvm-commits, t-tye
Differential Revision: https://reviews.llvm.org/D35167
llvm-svn: 310085
2017-08-05 02:36:49 +08:00
|
|
|
LowerToCopyInstrs.clear();
|
2016-03-22 04:28:33 +08:00
|
|
|
|
2016-06-24 14:30:11 +08:00
|
|
|
const SISubtarget &ST = MF.getSubtarget<SISubtarget>();
|
|
|
|
|
|
|
|
TII = ST.getInstrInfo();
|
|
|
|
TRI = &TII->getRegisterInfo();
|
2016-03-22 04:28:33 +08:00
|
|
|
MRI = &MF.getRegInfo();
|
2016-08-03 03:17:37 +08:00
|
|
|
LIS = &getAnalysis<LiveIntervals>();
|
2016-03-22 04:28:33 +08:00
|
|
|
|
|
|
|
char GlobalFlags = analyzeFunction(MF);
|
2016-04-22 12:04:08 +08:00
|
|
|
if (!(GlobalFlags & StateWQM)) {
|
|
|
|
lowerLiveMaskQueries(AMDGPU::EXEC);
|
|
|
|
return !LiveMaskQueries.empty();
|
|
|
|
}
|
2016-03-22 04:28:33 +08:00
|
|
|
|
2016-04-22 12:04:08 +08:00
|
|
|
// Store a copy of the original live mask when required
|
|
|
|
unsigned LiveMaskReg = 0;
|
2016-07-09 03:16:05 +08:00
|
|
|
{
|
|
|
|
MachineBasicBlock &Entry = MF.front();
|
|
|
|
MachineBasicBlock::iterator EntryMI = Entry.getFirstNonPHI();
|
|
|
|
|
|
|
|
if (GlobalFlags & StateExact || !LiveMaskQueries.empty()) {
|
|
|
|
LiveMaskReg = MRI->createVirtualRegister(&AMDGPU::SReg_64RegClass);
|
2016-09-13 00:25:20 +08:00
|
|
|
MachineInstr *MI = BuildMI(Entry, EntryMI, DebugLoc(),
|
|
|
|
TII->get(AMDGPU::COPY), LiveMaskReg)
|
|
|
|
.addReg(AMDGPU::EXEC);
|
|
|
|
LIS->InsertMachineInstrInMaps(*MI);
|
2016-07-09 03:16:05 +08:00
|
|
|
}
|
2016-04-22 12:04:08 +08:00
|
|
|
|
2016-07-09 03:16:05 +08:00
|
|
|
if (GlobalFlags == StateWQM) {
|
|
|
|
// For a shader that needs only WQM, we can just set it once.
|
|
|
|
BuildMI(Entry, EntryMI, DebugLoc(), TII->get(AMDGPU::S_WQM_B64),
|
|
|
|
AMDGPU::EXEC)
|
|
|
|
.addReg(AMDGPU::EXEC);
|
2016-04-22 12:04:08 +08:00
|
|
|
|
2016-07-09 03:16:05 +08:00
|
|
|
lowerLiveMaskQueries(LiveMaskReg);
|
[AMDGPU] Add an llvm.amdgcn.wqm intrinsic for WQM
Summary:
Previously, we assumed that certain types of instructions needed WQM in
pixel shaders, particularly DS instructions and image sampling
instructions. This was ok because with OpenGL, the assumption was
correct. But we want to start using DPP instructions for derivatives as
well as other things, so the assumption that we can infer whether to use
WQM based on the instruction won't continue to hold. This intrinsic lets
frontends like Mesa indicate what things need WQM based on their
knowledge of the API, rather than second-guessing them in the backend.
We need to keep around the old method of enabling WQM, but eventually we
should remove it once Mesa catches up. For now, this will let us use DPP
instructions for computing derivatives correctly.
Reviewers: arsenm, tpr, nhaehnle
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, llvm-commits, t-tye
Differential Revision: https://reviews.llvm.org/D35167
llvm-svn: 310085
2017-08-05 02:36:49 +08:00
|
|
|
lowerCopyInstrs();
|
2016-07-09 03:16:05 +08:00
|
|
|
// EntryMI may become invalid here
|
|
|
|
return true;
|
|
|
|
}
|
2016-03-22 04:28:33 +08:00
|
|
|
}
|
|
|
|
|
2016-09-03 20:26:38 +08:00
|
|
|
DEBUG(printInfo());
|
|
|
|
|
2016-04-22 12:04:08 +08:00
|
|
|
lowerLiveMaskQueries(LiveMaskReg);
|
[AMDGPU] Add an llvm.amdgcn.wqm intrinsic for WQM
Summary:
Previously, we assumed that certain types of instructions needed WQM in
pixel shaders, particularly DS instructions and image sampling
instructions. This was ok because with OpenGL, the assumption was
correct. But we want to start using DPP instructions for derivatives as
well as other things, so the assumption that we can infer whether to use
WQM based on the instruction won't continue to hold. This intrinsic lets
frontends like Mesa indicate what things need WQM based on their
knowledge of the API, rather than second-guessing them in the backend.
We need to keep around the old method of enabling WQM, but eventually we
should remove it once Mesa catches up. For now, this will let us use DPP
instructions for computing derivatives correctly.
Reviewers: arsenm, tpr, nhaehnle
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, llvm-commits, t-tye
Differential Revision: https://reviews.llvm.org/D35167
llvm-svn: 310085
2017-08-05 02:36:49 +08:00
|
|
|
lowerCopyInstrs();
|
2016-03-22 04:28:33 +08:00
|
|
|
|
2016-04-22 12:04:08 +08:00
|
|
|
// Handle the general case
|
2016-07-13 13:55:15 +08:00
|
|
|
for (auto BII : Blocks)
|
|
|
|
processBlock(*BII.first, LiveMaskReg, BII.first == &*MF.begin());
|
2016-03-22 04:28:33 +08:00
|
|
|
|
2016-09-13 00:25:20 +08:00
|
|
|
// Physical registers like SCC aren't tracked by default anyway, so just
|
|
|
|
// removing the ranges we computed is the simplest option for maintaining
|
|
|
|
// the analysis results.
|
|
|
|
LIS->removeRegUnit(*MCRegUnitIterator(AMDGPU::SCC, TRI));
|
|
|
|
|
2016-03-22 04:28:33 +08:00
|
|
|
return true;
|
|
|
|
}
|