2016-03-22 04:28:33 +08:00
|
|
|
//===-- SIWholeQuadMode.cpp - enter and suspend whole quad mode -----------===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2016-03-22 04:28:33 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
/// \file
|
2018-05-01 23:54:18 +08:00
|
|
|
/// This pass adds instructions to enable whole quad mode for pixel
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
/// shaders, and whole wavefront mode for all programs.
|
2016-03-22 04:28:33 +08:00
|
|
|
///
|
|
|
|
/// 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
|
|
|
|
///
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
/// We also compute when a sequence of instructions requires Whole Wavefront
|
|
|
|
/// Mode (WWM) and insert instructions to save and restore it:
|
|
|
|
///
|
|
|
|
/// S_OR_SAVEEXEC_B64 Tmp, -1
|
|
|
|
/// ...
|
|
|
|
/// S_MOV_B64 EXEC, Tmp
|
|
|
|
///
|
2016-03-22 04:28:33 +08:00
|
|
|
/// 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"
|
AMDGPU: Remove #include "MCTargetDesc/AMDGPUMCTargetDesc.h" from common headers
Summary:
MCTargetDesc/AMDGPUMCTargetDesc.h contains enums for all the instuction
and register defintions, which are huge so we only want to include
them where needed.
This will also make it easier if we want to split the R600 and GCN
definitions into separate tablegenerated files.
I was unable to remove AMDGPUMCTargetDesc.h from SIMachineFunctionInfo.h
because it uses some enums from the header to initialize default values
for the SIMachineFunction class, so I ended up having to remove includes of
SIMachineFunctionInfo.h from headers too.
Reviewers: arsenm, nhaehnle
Reviewed By: nhaehnle
Subscribers: MatzeB, kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D46272
llvm-svn: 332930
2018-05-22 10:03:23 +08:00
|
|
|
#include "MCTargetDesc/AMDGPUMCTargetDesc.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"
|
2017-12-13 10:51:04 +08:00
|
|
|
#include "llvm/CodeGen/LiveIntervals.h"
|
2016-12-10 06:06:55 +08:00
|
|
|
#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"
|
2017-11-17 09:07:10 +08:00
|
|
|
#include "llvm/CodeGen/TargetRegisterInfo.h"
|
2016-12-10 06:06:55 +08:00
|
|
|
#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 <cassert>
|
|
|
|
#include <vector>
|
2016-03-22 04:28:33 +08:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
#define DEBUG_TYPE "si-wqm"
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
enum {
|
|
|
|
StateWQM = 0x1,
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
StateWWM = 0x2,
|
|
|
|
StateExact = 0x4,
|
2016-03-22 04:28:33 +08:00
|
|
|
};
|
|
|
|
|
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
|
|
|
};
|
|
|
|
|
2017-11-16 11:18:15 +08:00
|
|
|
#ifndef NDEBUG
|
2016-09-03 20:26:38 +08:00
|
|
|
static raw_ostream &operator<<(raw_ostream &OS, const PrintState &PS) {
|
|
|
|
if (PS.State & StateWQM)
|
|
|
|
OS << "WQM";
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
if (PS.State & StateWWM) {
|
2016-09-03 20:26:38 +08:00
|
|
|
if (PS.State & StateWQM)
|
|
|
|
OS << '|';
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
OS << "WWM";
|
|
|
|
}
|
|
|
|
if (PS.State & StateExact) {
|
|
|
|
if (PS.State & (StateWQM | StateWWM))
|
|
|
|
OS << '|';
|
2016-09-03 20:26:38 +08:00
|
|
|
OS << "Exact";
|
|
|
|
}
|
|
|
|
|
|
|
|
return OS;
|
|
|
|
}
|
2017-11-16 11:18:15 +08:00
|
|
|
#endif
|
2016-09-03 20:26:38 +08:00
|
|
|
|
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:
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
CallingConv::ID CallingConv;
|
2016-03-22 04:28:33 +08:00
|
|
|
const SIInstrInfo *TII;
|
|
|
|
const SIRegisterInfo *TRI;
|
2019-06-17 01:13:09 +08:00
|
|
|
const GCNSubtarget *ST;
|
2016-03-22 04:28:33 +08:00
|
|
|
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);
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
void toWWM(MachineBasicBlock &MBB, MachineBasicBlock::iterator Before,
|
|
|
|
unsigned SaveOrig);
|
|
|
|
void fromWWM(MachineBasicBlock &MBB, MachineBasicBlock::iterator Before,
|
|
|
|
unsigned SavedOrig);
|
2016-03-22 04:28:33 +08:00
|
|
|
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>();
|
2019-03-26 00:47:42 +08:00
|
|
|
AU.addPreserved<SlotIndexes>();
|
|
|
|
AU.addPreserved<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;
|
|
|
|
}
|
|
|
|
|
2017-11-16 11:18:15 +08:00
|
|
|
#ifndef NDEBUG
|
2017-11-16 11:25:02 +08:00
|
|
|
LLVM_DUMP_METHOD void SIWholeQuadMode::printInfo() {
|
2016-09-03 20:26:38 +08:00
|
|
|
for (const auto &BII : Blocks) {
|
2017-12-05 01:18:51 +08:00
|
|
|
dbgs() << "\n"
|
|
|
|
<< printMBBReference(*BII.first) << ":\n"
|
2016-09-03 20:26:38 +08:00
|
|
|
<< " 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';
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2017-11-16 11:18:15 +08:00
|
|
|
#endif
|
2016-09-03 20:26:38 +08:00
|
|
|
|
2016-08-03 03:17:37 +08:00
|
|
|
void SIWholeQuadMode::markInstruction(MachineInstr &MI, char Flag,
|
|
|
|
std::vector<WorkItem> &Worklist) {
|
|
|
|
InstrInfo &II = Instructions[&MI];
|
|
|
|
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
assert(!(Flag & StateExact) && Flag != 0);
|
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) {
|
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)) {
|
2019-06-17 01:13:09 +08:00
|
|
|
if (Reg == AMDGPU::EXEC || Reg == AMDGPU::EXEC_LO)
|
2016-09-03 20:26:38 +08:00
|
|
|
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;
|
2017-12-16 06:22:58 +08:00
|
|
|
bool WQMOutputs = MF.getFunction().hasFnAttribute("amdgpu-ps-wqm-outputs");
|
2017-08-05 02:36:54 +08:00
|
|
|
SmallVector<MachineInstr *, 4> SetInactiveInstrs;
|
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
|
|
|
|
[AMDGPU] Don't force WQM for DS op
Summary:
Previously, all DS ops forced WQM in a pixel shader. That was a hack to
allow for graphics frontends using ds_swizzle to implement explicit
derivatives, on SI/CI at least where DPP is not available. But it forced
WQM for _any_ DS op.
With this commit, DS ops no longer force WQM. Both graphics frontends
(Mesa and LLPC) need to change to issue an explicit llvm.amdgcn.wqm
intrinsic call when calculating explicit derivatives.
The required Mesa change is: "amd/common: use llvm.amdgcn.wqm for
explicit derivatives".
Subscribers: qcolombet, arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D46051
Change-Id: I9b745b626fa91bbd66456e6cf41ee07eeea42f81
llvm-svn: 331633
2018-05-07 21:21:26 +08:00
|
|
|
if (TII->isWQM(Opcode)) {
|
2016-09-03 20:26:38 +08:00
|
|
|
// 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);
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
} else if (Opcode == AMDGPU::WWM) {
|
|
|
|
// The WWM intrinsic doesn't make the same guarantee, and plus it needs
|
|
|
|
// to be executed in WQM or Exact so that its copy doesn't clobber
|
|
|
|
// inactive lanes.
|
|
|
|
markInstructionUses(MI, StateWWM, Worklist);
|
|
|
|
GlobalFlags |= StateWWM;
|
|
|
|
LowerToCopyInstrs.push_back(&MI);
|
|
|
|
continue;
|
2017-08-05 02:36:54 +08:00
|
|
|
} else if (Opcode == AMDGPU::V_SET_INACTIVE_B32 ||
|
|
|
|
Opcode == AMDGPU::V_SET_INACTIVE_B64) {
|
|
|
|
III.Disabled = StateWWM;
|
|
|
|
MachineOperand &Inactive = MI.getOperand(2);
|
|
|
|
if (Inactive.isReg()) {
|
|
|
|
if (Inactive.isUndef()) {
|
|
|
|
LowerToCopyInstrs.push_back(&MI);
|
|
|
|
} else {
|
|
|
|
unsigned Reg = Inactive.getReg();
|
|
|
|
if (TargetRegisterInfo::isVirtualRegister(Reg)) {
|
|
|
|
for (MachineInstr &DefMI : MRI->def_instructions(Reg))
|
|
|
|
markInstruction(DefMI, StateWWM, Worklist);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
SetInactiveInstrs.push_back(&MI);
|
|
|
|
continue;
|
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;
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
III.Disabled = StateWQM | StateWWM;
|
[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
|
|
|
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) &&
|
2019-07-12 05:19:33 +08:00
|
|
|
TRI->hasVectorRegisters(TRI->getPhysRegClass(Reg))) {
|
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
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-08-05 02:36:54 +08:00
|
|
|
// Mark sure that any SET_INACTIVE instructions are computed in WQM if WQM is
|
|
|
|
// ever used anywhere in the function. This implements the corresponding
|
|
|
|
// semantics of @llvm.amdgcn.set.inactive.
|
|
|
|
if (GlobalFlags & StateWQM) {
|
|
|
|
for (MachineInstr *MI : SetInactiveInstrs)
|
|
|
|
markInstruction(*MI, StateWQM, Worklist);
|
|
|
|
}
|
|
|
|
|
2016-03-22 04:28:33 +08:00
|
|
|
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()) {
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
char InNeeds = (II.Needs & ~StateWWM) | II.OutNeeds;
|
2016-03-22 04:28:33 +08:00
|
|
|
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);
|
2018-05-28 01:26:11 +08:00
|
|
|
|
|
|
|
// Ensure we process a block containing WWM, even if it does not require any
|
|
|
|
// WQM transitions.
|
|
|
|
if (II.Needs & StateWWM)
|
|
|
|
BI.Needs |= StateWWM;
|
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) {
|
2019-06-17 01:13:09 +08:00
|
|
|
MI = BuildMI(MBB, Before, DebugLoc(), TII->get(ST->isWave32() ?
|
|
|
|
AMDGPU::S_AND_SAVEEXEC_B32 : AMDGPU::S_AND_SAVEEXEC_B64),
|
2016-09-13 00:25:20 +08:00
|
|
|
SaveWQM)
|
|
|
|
.addReg(LiveMaskReg);
|
2016-03-22 04:28:33 +08:00
|
|
|
} else {
|
2019-06-17 01:13:09 +08:00
|
|
|
unsigned Exec = ST->isWave32() ? AMDGPU::EXEC_LO : AMDGPU::EXEC;
|
|
|
|
MI = BuildMI(MBB, Before, DebugLoc(), TII->get(ST->isWave32() ?
|
|
|
|
AMDGPU::S_AND_B32 : AMDGPU::S_AND_B64),
|
|
|
|
Exec)
|
|
|
|
.addReg(Exec)
|
2016-09-13 00:25:20 +08:00
|
|
|
.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;
|
|
|
|
|
2019-06-17 01:13:09 +08:00
|
|
|
unsigned Exec = ST->isWave32() ? AMDGPU::EXEC_LO : AMDGPU::EXEC;
|
2016-03-22 04:28:33 +08:00
|
|
|
if (SavedWQM) {
|
2019-06-17 01:13:09 +08:00
|
|
|
MI = BuildMI(MBB, Before, DebugLoc(), TII->get(AMDGPU::COPY), Exec)
|
2016-09-13 00:25:20 +08:00
|
|
|
.addReg(SavedWQM);
|
2016-03-22 04:28:33 +08:00
|
|
|
} else {
|
2019-06-17 01:13:09 +08:00
|
|
|
MI = BuildMI(MBB, Before, DebugLoc(), TII->get(ST->isWave32() ?
|
|
|
|
AMDGPU::S_WQM_B32 : AMDGPU::S_WQM_B64),
|
|
|
|
Exec)
|
|
|
|
.addReg(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
|
|
|
}
|
|
|
|
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
void SIWholeQuadMode::toWWM(MachineBasicBlock &MBB,
|
|
|
|
MachineBasicBlock::iterator Before,
|
|
|
|
unsigned SaveOrig) {
|
|
|
|
MachineInstr *MI;
|
|
|
|
|
|
|
|
assert(SaveOrig);
|
2019-04-01 23:19:52 +08:00
|
|
|
MI = BuildMI(MBB, Before, DebugLoc(), TII->get(AMDGPU::ENTER_WWM), SaveOrig)
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
.addImm(-1);
|
|
|
|
LIS->InsertMachineInstrInMaps(*MI);
|
|
|
|
}
|
|
|
|
|
|
|
|
void SIWholeQuadMode::fromWWM(MachineBasicBlock &MBB,
|
|
|
|
MachineBasicBlock::iterator Before,
|
|
|
|
unsigned SavedOrig) {
|
|
|
|
MachineInstr *MI;
|
|
|
|
|
|
|
|
assert(SavedOrig);
|
2019-06-17 01:13:09 +08:00
|
|
|
MI = BuildMI(MBB, Before, DebugLoc(), TII->get(AMDGPU::EXIT_WWM),
|
|
|
|
ST->isWave32() ? AMDGPU::EXEC_LO : AMDGPU::EXEC)
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
.addReg(SavedOrig);
|
|
|
|
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;
|
|
|
|
|
|
|
|
// This is a non-entry block that is WQM throughout, so no need to do
|
|
|
|
// anything.
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
if (!isEntry && BI.Needs == StateWQM && BI.OutNeeds != StateExact)
|
2016-03-22 04:28:33 +08:00
|
|
|
return;
|
|
|
|
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << "\nProcessing block " << printMBBReference(MBB)
|
|
|
|
<< ":\n");
|
2016-09-03 20:26:38 +08:00
|
|
|
|
2016-03-22 04:28:33 +08:00
|
|
|
unsigned SavedWQMReg = 0;
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
unsigned SavedNonWWMReg = 0;
|
2016-03-22 04:28:33 +08:00
|
|
|
bool WQMFromExec = isEntry;
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
char State = (isEntry || !(BI.InNeeds & StateWQM)) ? StateExact : StateWQM;
|
|
|
|
char NonWWMState = 0;
|
2019-06-17 01:13:09 +08:00
|
|
|
const TargetRegisterClass *BoolRC = TRI->getBoolRC();
|
2016-03-22 04:28:33 +08:00
|
|
|
|
|
|
|
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
|
|
|
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
// This stores the first instruction where it's safe to switch from WQM to
|
|
|
|
// Exact or vice versa.
|
|
|
|
MachineBasicBlock::iterator FirstWQM = IE;
|
|
|
|
|
|
|
|
// This stores the first instruction where it's safe to switch from WWM to
|
|
|
|
// Exact/WQM or to switch to WWM. It must always be the same as, or after,
|
|
|
|
// FirstWQM since if it's safe to switch to/from WWM, it must be safe to
|
|
|
|
// switch to/from WQM as well.
|
|
|
|
MachineBasicBlock::iterator FirstWWM = IE;
|
2016-09-13 00:25:20 +08:00
|
|
|
for (;;) {
|
|
|
|
MachineBasicBlock::iterator Next = II;
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
char Needs = StateExact | StateWQM; // WWM is disabled by default
|
2016-09-13 00:25:20 +08:00
|
|
|
char OutNeeds = 0;
|
2016-03-22 04:28:33 +08:00
|
|
|
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
if (FirstWQM == IE)
|
|
|
|
FirstWQM = II;
|
|
|
|
|
|
|
|
if (FirstWWM == IE)
|
|
|
|
FirstWWM = II;
|
2016-09-13 00:25:20 +08:00
|
|
|
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
// First, figure out the allowed states (Needs) based on the propagated
|
|
|
|
// flags.
|
2016-09-13 00:25:20 +08:00
|
|
|
if (II != IE) {
|
|
|
|
MachineInstr &MI = *II;
|
|
|
|
|
|
|
|
if (requiresCorrectState(MI)) {
|
|
|
|
auto III = Instructions.find(&MI);
|
|
|
|
if (III != Instructions.end()) {
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
if (III->second.Needs & StateWWM)
|
|
|
|
Needs = StateWWM;
|
|
|
|
else if (III->second.Needs & StateWQM)
|
[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
|
|
|
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] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
} else {
|
|
|
|
// If the instruction doesn't actually need a correct EXEC, then we can
|
|
|
|
// safely leave WWM enabled.
|
|
|
|
Needs = StateExact | StateWQM | StateWWM;
|
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] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
// Now, transition if necessary.
|
[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)) {
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
MachineBasicBlock::iterator First;
|
|
|
|
if (State == StateWWM || Needs == StateWWM) {
|
|
|
|
// We must switch to or from WWM
|
|
|
|
First = FirstWWM;
|
|
|
|
} else {
|
|
|
|
// We only need to switch to/from WQM, so we can use FirstWQM
|
|
|
|
First = FirstWQM;
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
MachineBasicBlock::iterator Before =
|
|
|
|
prepareInsertion(MBB, First, II, Needs == StateWQM,
|
|
|
|
Needs == StateExact || WQMFromExec);
|
2016-09-03 20:26:38 +08:00
|
|
|
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
if (State == StateWWM) {
|
|
|
|
assert(SavedNonWWMReg);
|
|
|
|
fromWWM(MBB, Before, SavedNonWWMReg);
|
|
|
|
State = NonWWMState;
|
|
|
|
}
|
2016-03-22 04:28:33 +08:00
|
|
|
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
if (Needs == StateWWM) {
|
|
|
|
NonWWMState = State;
|
2019-06-17 01:13:09 +08:00
|
|
|
SavedNonWWMReg = MRI->createVirtualRegister(BoolRC);
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
toWWM(MBB, Before, SavedNonWWMReg);
|
|
|
|
State = StateWWM;
|
[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 {
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
if (State == StateWQM && (Needs & StateExact) && !(Needs & StateWQM)) {
|
|
|
|
if (!WQMFromExec && (OutNeeds & StateWQM))
|
2019-06-17 01:13:09 +08:00
|
|
|
SavedWQMReg = MRI->createVirtualRegister(BoolRC);
|
2016-03-22 04:28:33 +08:00
|
|
|
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
toExact(MBB, Before, SavedWQMReg, LiveMaskReg);
|
|
|
|
State = StateExact;
|
|
|
|
} else if (State == StateExact && (Needs & StateWQM) &&
|
|
|
|
!(Needs & StateExact)) {
|
|
|
|
assert(WQMFromExec == (SavedWQMReg == 0));
|
2016-09-13 00:25:20 +08:00
|
|
|
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
toWQM(MBB, Before, SavedWQMReg);
|
|
|
|
|
|
|
|
if (SavedWQMReg) {
|
|
|
|
LIS->createAndComputeVirtRegInterval(SavedWQMReg);
|
|
|
|
SavedWQMReg = 0;
|
|
|
|
}
|
|
|
|
State = StateWQM;
|
|
|
|
} else {
|
|
|
|
// We can get here if we transitioned from WWM to a non-WWM state that
|
|
|
|
// already matches our needs, but we shouldn't need to do anything.
|
|
|
|
assert(Needs & State);
|
2016-09-13 00:25:20 +08:00
|
|
|
}
|
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] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
if (Needs != (StateExact | StateWQM | StateWWM)) {
|
|
|
|
if (Needs != (StateExact | StateWQM))
|
|
|
|
FirstWQM = IE;
|
|
|
|
FirstWWM = IE;
|
|
|
|
}
|
[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
|
|
|
|
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() {
|
2017-08-05 02:36:54 +08:00
|
|
|
for (MachineInstr *MI : LowerToCopyInstrs) {
|
|
|
|
for (unsigned i = MI->getNumExplicitOperands() - 1; i > 1; i--)
|
|
|
|
MI->RemoveOperand(i);
|
2019-04-01 23:19:52 +08:00
|
|
|
|
|
|
|
const unsigned Reg = MI->getOperand(0).getReg();
|
|
|
|
|
|
|
|
if (TRI->isVGPR(*MRI, Reg)) {
|
|
|
|
const TargetRegisterClass *regClass =
|
|
|
|
TargetRegisterInfo::isVirtualRegister(Reg)
|
|
|
|
? MRI->getRegClass(Reg)
|
|
|
|
: TRI->getPhysRegClass(Reg);
|
|
|
|
|
|
|
|
const unsigned MovOp = TII->getMovOpcode(regClass);
|
|
|
|
MI->setDesc(TII->get(MovOp));
|
|
|
|
|
|
|
|
// And make it implicitly depend on exec (like all VALU movs should do).
|
|
|
|
MI->addOperand(MachineOperand::CreateReg(AMDGPU::EXEC, false, true));
|
|
|
|
} else {
|
|
|
|
MI->setDesc(TII->get(AMDGPU::COPY));
|
|
|
|
}
|
2017-08-05 02:36:54 +08:00
|
|
|
}
|
[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
|
|
|
}
|
|
|
|
|
2016-03-22 04:28:33 +08:00
|
|
|
bool SIWholeQuadMode::runOnMachineFunction(MachineFunction &MF) {
|
|
|
|
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();
|
2017-12-16 06:22:58 +08:00
|
|
|
CallingConv = MF.getFunction().getCallingConv();
|
2016-03-22 04:28:33 +08:00
|
|
|
|
2019-06-17 01:13:09 +08:00
|
|
|
ST = &MF.getSubtarget<GCNSubtarget>();
|
2016-06-24 14:30:11 +08:00
|
|
|
|
2019-06-17 01:13:09 +08:00
|
|
|
TII = ST->getInstrInfo();
|
2016-06-24 14:30:11 +08:00
|
|
|
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);
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
unsigned LiveMaskReg = 0;
|
2019-06-17 01:13:09 +08:00
|
|
|
unsigned Exec = ST->isWave32() ? AMDGPU::EXEC_LO : AMDGPU::EXEC;
|
2016-04-22 12:04:08 +08:00
|
|
|
if (!(GlobalFlags & StateWQM)) {
|
2019-06-17 01:13:09 +08:00
|
|
|
lowerLiveMaskQueries(Exec);
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
if (!(GlobalFlags & StateWWM))
|
|
|
|
return !LiveMaskQueries.empty();
|
|
|
|
} else {
|
|
|
|
// Store a copy of the original live mask when required
|
2016-07-09 03:16:05 +08:00
|
|
|
MachineBasicBlock &Entry = MF.front();
|
|
|
|
MachineBasicBlock::iterator EntryMI = Entry.getFirstNonPHI();
|
|
|
|
|
|
|
|
if (GlobalFlags & StateExact || !LiveMaskQueries.empty()) {
|
2019-06-17 01:13:09 +08:00
|
|
|
LiveMaskReg = MRI->createVirtualRegister(TRI->getBoolRC());
|
2016-09-13 00:25:20 +08:00
|
|
|
MachineInstr *MI = BuildMI(Entry, EntryMI, DebugLoc(),
|
|
|
|
TII->get(AMDGPU::COPY), LiveMaskReg)
|
2019-06-17 01:13:09 +08:00
|
|
|
.addReg(Exec);
|
2016-09-13 00:25:20 +08:00
|
|
|
LIS->InsertMachineInstrInMaps(*MI);
|
2016-07-09 03:16:05 +08:00
|
|
|
}
|
2016-04-22 12:04:08 +08:00
|
|
|
|
[AMDGPU] Add support for Whole Wavefront Mode
Summary:
Whole Wavefront Wode (WWM) is similar to WQM, except that all of the
lanes are always enabled, regardless of control flow. This is required
for implementing wavefront reductions in non-uniform control flow, where
we need to use the inactive lanes to propagate intermediate results, so
they need to be enabled. We need to propagate WWM to uses (unless
they're explicitly marked as exact) so that they also propagate
intermediate results correctly. We do the analysis and exec mask munging
during the WQM pass, since there are interactions with WQM for things
that require both WQM and WWM. For simplicity, WWM is entirely
block-local -- blocks are never WWM on entry or exit of a block, and WWM
is not propagated to the block level. This means that computations
involving WWM cannot involve control flow, but we only ever plan to use
WWM for a few limited purposes (none of which involve control flow)
anyways.
Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There
isn't yet a way to turn WWM off -- that will be added in a future
change.
Finally, it turns out that turning on inactive lanes causes a number of
problems with register allocation. While the best long-term solution
seems like teaching LLVM's register allocator about predication, for now
we need to add some hacks to prevent ourselves from getting into trouble
due to constraints that aren't currently expressed in LLVM. For the gory
details, see the comments at the top of SIFixWWMLiveness.cpp.
Reviewers: arsenm, nhaehnle, tpr
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D35524
llvm-svn: 310087
2017-08-05 02:36:52 +08:00
|
|
|
lowerLiveMaskQueries(LiveMaskReg);
|
|
|
|
|
2016-07-09 03:16:05 +08:00
|
|
|
if (GlobalFlags == StateWQM) {
|
|
|
|
// For a shader that needs only WQM, we can just set it once.
|
2019-06-17 01:13:09 +08:00
|
|
|
BuildMI(Entry, EntryMI, DebugLoc(), TII->get(ST->isWave32() ?
|
|
|
|
AMDGPU::S_WQM_B32 : AMDGPU::S_WQM_B64),
|
|
|
|
Exec)
|
|
|
|
.addReg(Exec);
|
2016-04-22 12:04:08 +08:00
|
|
|
|
[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
|
|
|
}
|
|
|
|
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(printInfo());
|
2016-09-03 20:26:38 +08:00
|
|
|
|
[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;
|
|
|
|
}
|