2017-02-14 08:33:36 +08:00
|
|
|
//===- AMDGPUBaseInfo.h - Top level definitions for AMDGPU ------*- C++ -*-===//
|
2015-06-27 05:15:07 +08:00
|
|
|
//
|
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
|
2015-06-27 05:15:07 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef LLVM_LIB_TARGET_AMDGPU_UTILS_AMDGPUBASEINFO_H
|
|
|
|
#define LLVM_LIB_TARGET_AMDGPU_UTILS_AMDGPUBASEINFO_H
|
|
|
|
|
2017-03-27 22:04:01 +08:00
|
|
|
#include "AMDGPU.h"
|
2015-06-27 05:15:07 +08:00
|
|
|
#include "AMDKernelCodeT.h"
|
2016-12-10 08:39:12 +08:00
|
|
|
#include "SIDefines.h"
|
2017-02-14 08:33:36 +08:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
|
|
|
#include "llvm/IR/CallingConv.h"
|
|
|
|
#include "llvm/MC/MCInstrDesc.h"
|
2018-06-22 03:38:56 +08:00
|
|
|
#include "llvm/Support/AMDHSAKernelDescriptor.h"
|
2017-02-14 08:33:36 +08:00
|
|
|
#include "llvm/Support/Compiler.h"
|
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
2018-09-13 02:50:47 +08:00
|
|
|
#include "llvm/Support/TargetParser.h"
|
2017-02-14 08:33:36 +08:00
|
|
|
#include <cstdint>
|
2017-10-14 23:40:33 +08:00
|
|
|
#include <string>
|
2017-02-14 08:33:36 +08:00
|
|
|
#include <utility>
|
2016-12-10 08:39:12 +08:00
|
|
|
|
2015-06-27 05:15:07 +08:00
|
|
|
namespace llvm {
|
|
|
|
|
2017-07-27 04:39:42 +08:00
|
|
|
class Argument;
|
[AMDGPU] New buffer intrinsics
Summary:
This commit adds new intrinsics
llvm.amdgcn.raw.buffer.load
llvm.amdgcn.raw.buffer.load.format
llvm.amdgcn.raw.buffer.load.format.d16
llvm.amdgcn.struct.buffer.load
llvm.amdgcn.struct.buffer.load.format
llvm.amdgcn.struct.buffer.load.format.d16
llvm.amdgcn.raw.buffer.store
llvm.amdgcn.raw.buffer.store.format
llvm.amdgcn.raw.buffer.store.format.d16
llvm.amdgcn.struct.buffer.store
llvm.amdgcn.struct.buffer.store.format
llvm.amdgcn.struct.buffer.store.format.d16
llvm.amdgcn.raw.buffer.atomic.*
llvm.amdgcn.struct.buffer.atomic.*
with the following changes from the llvm.amdgcn.buffer.*
intrinsics:
* there are separate raw and struct versions: raw does not have an
index arg and sets idxen=0 in the instruction, and struct always sets
idxen=1 in the instruction even if the index is 0, to allow for the
fact that gfx9 does bounds checking differently depending on whether
idxen is set;
* there is a combined cachepolicy arg (glc+slc)
* there are now only two offset args: one for the offset that is
included in bounds checking and swizzling, to be split between the
instruction's voffset and immoffset fields, and one for the offset
that is excluded from bounds checking and swizzling, to go into the
instruction's soffset field.
The AMDISD::BUFFER_* SD nodes always have an index operand, all three
offset operands, combined cachepolicy operand, and an extra idxen
operand.
The obsolescent llvm.amdgcn.buffer.* intrinsics continue to work.
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, t-tye, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D50306
Change-Id: If897ea7dc34fcbf4d5496e98cc99a934f62fc205
llvm-svn: 340269
2018-08-21 19:07:10 +08:00
|
|
|
class AMDGPUSubtarget;
|
2015-06-27 05:15:07 +08:00
|
|
|
class FeatureBitset;
|
2015-12-16 00:26:16 +08:00
|
|
|
class Function;
|
[AMDGPU] New buffer intrinsics
Summary:
This commit adds new intrinsics
llvm.amdgcn.raw.buffer.load
llvm.amdgcn.raw.buffer.load.format
llvm.amdgcn.raw.buffer.load.format.d16
llvm.amdgcn.struct.buffer.load
llvm.amdgcn.struct.buffer.load.format
llvm.amdgcn.struct.buffer.load.format.d16
llvm.amdgcn.raw.buffer.store
llvm.amdgcn.raw.buffer.store.format
llvm.amdgcn.raw.buffer.store.format.d16
llvm.amdgcn.struct.buffer.store
llvm.amdgcn.struct.buffer.store.format
llvm.amdgcn.struct.buffer.store.format.d16
llvm.amdgcn.raw.buffer.atomic.*
llvm.amdgcn.struct.buffer.atomic.*
with the following changes from the llvm.amdgcn.buffer.*
intrinsics:
* there are separate raw and struct versions: raw does not have an
index arg and sets idxen=0 in the instruction, and struct always sets
idxen=1 in the instruction even if the index is 0, to allow for the
fact that gfx9 does bounds checking differently depending on whether
idxen is set;
* there is a combined cachepolicy arg (glc+slc)
* there are now only two offset args: one for the offset that is
included in bounds checking and swizzling, to be split between the
instruction's voffset and immoffset fields, and one for the offset
that is excluded from bounds checking and swizzling, to go into the
instruction's soffset field.
The AMDISD::BUFFER_* SD nodes always have an index operand, all three
offset operands, combined cachepolicy operand, and an extra idxen
operand.
The obsolescent llvm.amdgcn.buffer.* intrinsics continue to work.
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, t-tye, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D50306
Change-Id: If897ea7dc34fcbf4d5496e98cc99a934f62fc205
llvm-svn: 340269
2018-08-21 19:07:10 +08:00
|
|
|
class GCNSubtarget;
|
2015-12-03 01:00:42 +08:00
|
|
|
class GlobalValue;
|
2015-09-26 05:41:28 +08:00
|
|
|
class MCContext;
|
2016-10-20 01:40:36 +08:00
|
|
|
class MCRegisterClass;
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 22:44:04 +08:00
|
|
|
class MCRegisterInfo;
|
2015-09-26 05:41:28 +08:00
|
|
|
class MCSection;
|
2015-12-22 02:44:27 +08:00
|
|
|
class MCSubtargetInfo;
|
2018-06-22 03:38:56 +08:00
|
|
|
class MachineMemOperand;
|
2017-02-14 08:33:36 +08:00
|
|
|
class Triple;
|
2015-06-27 05:15:07 +08:00
|
|
|
|
|
|
|
namespace AMDGPU {
|
2018-06-21 21:36:44 +08:00
|
|
|
|
|
|
|
#define GET_MIMGBaseOpcode_DECL
|
AMDGPU: Select MIMG instructions manually in SITargetLowering
Summary:
Having TableGen patterns for image intrinsics is hitting limitations:
for D16 we already have to manually pre-lower the packing of data
values, and we will have to do the same for A16 eventually.
Since there is already some custom C++ code anyway, it is arguably easier
to just do everything in C++, now that we can use the beefed-up generic
tables backend of TableGen to provide all the required metadata and map
intrinsics to corresponding opcodes. With this approach, all image
intrinsic lowering happens in SITargetLowering::lowerImage. That code is
dense due to all the cases that it handles, but it should still be easier
to follow than what we had before, by virtue of it all being done in a
single location, and by virtue of not relying on the TableGen pattern
magic that very few people really understand.
This means that we will have MachineSDNodes with MIMG instructions
during DAG combining, but that seems alright: previously we had
intrinsic nodes instead, but those are similarly opaque to the generic
CodeGen infrastructure, and the final pattern matching just did a 1:1
translation to machine instructions anyway. If anything, the fact that
we now merge the address words into a vector before DAG combine should
be an advantage.
Change-Id: I417f26bd88f54ce9781c1668acc01f3f99774de6
Reviewers: arsenm, rampitec, rtaylor, tstellar
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D48017
llvm-svn: 335228
2018-06-21 21:36:57 +08:00
|
|
|
#define GET_MIMGDim_DECL
|
2018-06-21 21:36:44 +08:00
|
|
|
#define GET_MIMGEncoding_DECL
|
[AMDGPU] Optimize _L image intrinsic to _LZ when lod is zero
Summary:
Add _L to _LZ image intrinsic table mapping to table gen.
In ISelLowering check if image intrinsic has lod and if it's equal
to zero, if so remove lod and change opcode to equivalent mapped _LZ.
Change-Id: Ie24cd7e788e2195d846c7bd256151178cbb9ec71
Subscribers: arsenm, mehdi_amini, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, steven_wu, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D49483
llvm-svn: 338523
2018-08-01 20:12:01 +08:00
|
|
|
#define GET_MIMGLZMapping_DECL
|
2018-06-21 21:36:44 +08:00
|
|
|
#include "AMDGPUGenSearchableTables.inc"
|
|
|
|
|
2017-02-08 22:05:23 +08:00
|
|
|
namespace IsaInfo {
|
2016-10-07 22:46:06 +08:00
|
|
|
|
2017-02-08 22:05:23 +08:00
|
|
|
enum {
|
|
|
|
// The closed Vulkan driver sets 96, which limits the wave count to 8 but
|
|
|
|
// doesn't spill SGPRs as much as when 80 is set.
|
2018-05-17 04:47:48 +08:00
|
|
|
FIXED_NUM_SGPRS_FOR_INIT_BUG = 96,
|
|
|
|
TRAP_NUM_SGPRS = 16
|
2017-02-08 22:05:23 +08:00
|
|
|
};
|
|
|
|
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Streams isa version string for given subtarget \p STI into \p Stream.
|
2017-10-14 23:40:33 +08:00
|
|
|
void streamIsaVersion(const MCSubtargetInfo *STI, raw_ostream &Stream);
|
|
|
|
|
2018-06-13 02:02:46 +08:00
|
|
|
/// \returns True if given subtarget \p STI supports code object version 3,
|
2017-10-14 23:59:07 +08:00
|
|
|
/// false otherwise.
|
2018-06-13 02:02:46 +08:00
|
|
|
bool hasCodeObjectV3(const MCSubtargetInfo *STI);
|
2017-10-14 23:59:07 +08:00
|
|
|
|
2018-09-13 02:50:47 +08:00
|
|
|
/// \returns Wavefront size for given subtarget \p STI.
|
|
|
|
unsigned getWavefrontSize(const MCSubtargetInfo *STI);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
2018-09-13 02:50:47 +08:00
|
|
|
/// \returns Local memory size in bytes for given subtarget \p STI.
|
|
|
|
unsigned getLocalMemorySize(const MCSubtargetInfo *STI);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
|
|
|
/// \returns Number of execution units per compute unit for given subtarget \p
|
2018-09-13 02:50:47 +08:00
|
|
|
/// STI.
|
|
|
|
unsigned getEUsPerCU(const MCSubtargetInfo *STI);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
|
|
|
/// \returns Maximum number of work groups per compute unit for given subtarget
|
2018-09-13 02:50:47 +08:00
|
|
|
/// \p STI and limited by given \p FlatWorkGroupSize.
|
|
|
|
unsigned getMaxWorkGroupsPerCU(const MCSubtargetInfo *STI,
|
2017-02-08 22:05:23 +08:00
|
|
|
unsigned FlatWorkGroupSize);
|
|
|
|
|
|
|
|
/// \returns Maximum number of waves per compute unit for given subtarget \p
|
2018-09-13 02:50:47 +08:00
|
|
|
/// STI without any kind of limitation.
|
|
|
|
unsigned getMaxWavesPerCU(const MCSubtargetInfo *STI);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
|
|
|
/// \returns Maximum number of waves per compute unit for given subtarget \p
|
2018-09-13 02:50:47 +08:00
|
|
|
/// STI and limited by given \p FlatWorkGroupSize.
|
|
|
|
unsigned getMaxWavesPerCU(const MCSubtargetInfo *STI,
|
2017-02-08 22:05:23 +08:00
|
|
|
unsigned FlatWorkGroupSize);
|
|
|
|
|
|
|
|
/// \returns Minimum number of waves per execution unit for given subtarget \p
|
2018-09-13 02:50:47 +08:00
|
|
|
/// STI.
|
|
|
|
unsigned getMinWavesPerEU(const MCSubtargetInfo *STI);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
|
|
|
/// \returns Maximum number of waves per execution unit for given subtarget \p
|
2018-09-13 02:50:47 +08:00
|
|
|
/// STI without any kind of limitation.
|
AMDGPU: Separate R600 and GCN TableGen files
Summary:
We now have two sets of generated TableGen files, one for R600 and one
for GCN, so each sub-target now has its own tables of instructions,
registers, ISel patterns, etc. This should help reduce compile time
since each sub-target now only has to consider information that
is specific to itself. This will also help prevent the R600
sub-target from slowing down new features for GCN, like disassembler
support, GlobalISel, etc.
Reviewers: arsenm, nhaehnle, jvesely
Reviewed By: arsenm
Subscribers: MatzeB, kzhuravl, wdng, mgorny, yaxunl, dstuttard, tpr, t-tye, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D46365
llvm-svn: 335942
2018-06-29 07:47:12 +08:00
|
|
|
unsigned getMaxWavesPerEU();
|
2017-02-08 22:05:23 +08:00
|
|
|
|
|
|
|
/// \returns Maximum number of waves per execution unit for given subtarget \p
|
2018-09-13 02:50:47 +08:00
|
|
|
/// STI and limited by given \p FlatWorkGroupSize.
|
|
|
|
unsigned getMaxWavesPerEU(const MCSubtargetInfo *STI,
|
2017-02-08 22:05:23 +08:00
|
|
|
unsigned FlatWorkGroupSize);
|
|
|
|
|
2018-09-13 02:50:47 +08:00
|
|
|
/// \returns Minimum flat work group size for given subtarget \p STI.
|
|
|
|
unsigned getMinFlatWorkGroupSize(const MCSubtargetInfo *STI);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
2018-09-13 02:50:47 +08:00
|
|
|
/// \returns Maximum flat work group size for given subtarget \p STI.
|
|
|
|
unsigned getMaxFlatWorkGroupSize(const MCSubtargetInfo *STI);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
2018-09-13 02:50:47 +08:00
|
|
|
/// \returns Number of waves per work group for given subtarget \p STI and
|
2017-02-08 22:05:23 +08:00
|
|
|
/// limited by given \p FlatWorkGroupSize.
|
2018-09-13 02:50:47 +08:00
|
|
|
unsigned getWavesPerWorkGroup(const MCSubtargetInfo *STI,
|
2017-02-08 22:05:23 +08:00
|
|
|
unsigned FlatWorkGroupSize);
|
|
|
|
|
2018-09-13 02:50:47 +08:00
|
|
|
/// \returns SGPR allocation granularity for given subtarget \p STI.
|
|
|
|
unsigned getSGPRAllocGranule(const MCSubtargetInfo *STI);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
2018-09-13 02:50:47 +08:00
|
|
|
/// \returns SGPR encoding granularity for given subtarget \p STI.
|
|
|
|
unsigned getSGPREncodingGranule(const MCSubtargetInfo *STI);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
2018-09-13 02:50:47 +08:00
|
|
|
/// \returns Total number of SGPRs for given subtarget \p STI.
|
|
|
|
unsigned getTotalNumSGPRs(const MCSubtargetInfo *STI);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
2018-09-13 02:50:47 +08:00
|
|
|
/// \returns Addressable number of SGPRs for given subtarget \p STI.
|
|
|
|
unsigned getAddressableNumSGPRs(const MCSubtargetInfo *STI);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
|
|
|
/// \returns Minimum number of SGPRs that meets the given number of waves per
|
2018-09-13 02:50:47 +08:00
|
|
|
/// execution unit requirement for given subtarget \p STI.
|
|
|
|
unsigned getMinNumSGPRs(const MCSubtargetInfo *STI, unsigned WavesPerEU);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
|
|
|
/// \returns Maximum number of SGPRs that meets the given number of waves per
|
2018-09-13 02:50:47 +08:00
|
|
|
/// execution unit requirement for given subtarget \p STI.
|
|
|
|
unsigned getMaxNumSGPRs(const MCSubtargetInfo *STI, unsigned WavesPerEU,
|
2017-02-08 22:05:23 +08:00
|
|
|
bool Addressable);
|
|
|
|
|
2018-06-22 03:38:56 +08:00
|
|
|
/// \returns Number of extra SGPRs implicitly required by given subtarget \p
|
2018-09-13 02:50:47 +08:00
|
|
|
/// STI when the given special registers are used.
|
|
|
|
unsigned getNumExtraSGPRs(const MCSubtargetInfo *STI, bool VCCUsed,
|
2018-06-22 03:38:56 +08:00
|
|
|
bool FlatScrUsed, bool XNACKUsed);
|
|
|
|
|
|
|
|
/// \returns Number of extra SGPRs implicitly required by given subtarget \p
|
2018-09-13 02:50:47 +08:00
|
|
|
/// STI when the given special registers are used. XNACK is inferred from
|
|
|
|
/// \p STI.
|
|
|
|
unsigned getNumExtraSGPRs(const MCSubtargetInfo *STI, bool VCCUsed,
|
2018-06-22 03:38:56 +08:00
|
|
|
bool FlatScrUsed);
|
|
|
|
|
2018-09-13 02:50:47 +08:00
|
|
|
/// \returns Number of SGPR blocks needed for given subtarget \p STI when
|
2018-06-22 03:38:56 +08:00
|
|
|
/// \p NumSGPRs are used. \p NumSGPRs should already include any special
|
|
|
|
/// register counts.
|
2018-09-13 02:50:47 +08:00
|
|
|
unsigned getNumSGPRBlocks(const MCSubtargetInfo *STI, unsigned NumSGPRs);
|
2018-06-22 03:38:56 +08:00
|
|
|
|
2018-09-13 02:50:47 +08:00
|
|
|
/// \returns VGPR allocation granularity for given subtarget \p STI.
|
|
|
|
unsigned getVGPRAllocGranule(const MCSubtargetInfo *STI);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
2018-09-13 02:50:47 +08:00
|
|
|
/// \returns VGPR encoding granularity for given subtarget \p STI.
|
|
|
|
unsigned getVGPREncodingGranule(const MCSubtargetInfo *STI);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
2018-09-13 02:50:47 +08:00
|
|
|
/// \returns Total number of VGPRs for given subtarget \p STI.
|
|
|
|
unsigned getTotalNumVGPRs(const MCSubtargetInfo *STI);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
2018-09-13 02:50:47 +08:00
|
|
|
/// \returns Addressable number of VGPRs for given subtarget \p STI.
|
|
|
|
unsigned getAddressableNumVGPRs(const MCSubtargetInfo *STI);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
|
|
|
/// \returns Minimum number of VGPRs that meets given number of waves per
|
2018-09-13 02:50:47 +08:00
|
|
|
/// execution unit requirement for given subtarget \p STI.
|
|
|
|
unsigned getMinNumVGPRs(const MCSubtargetInfo *STI, unsigned WavesPerEU);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
|
|
|
/// \returns Maximum number of VGPRs that meets given number of waves per
|
2018-09-13 02:50:47 +08:00
|
|
|
/// execution unit requirement for given subtarget \p STI.
|
|
|
|
unsigned getMaxNumVGPRs(const MCSubtargetInfo *STI, unsigned WavesPerEU);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
2018-09-13 02:50:47 +08:00
|
|
|
/// \returns Number of VGPR blocks needed for given subtarget \p STI when
|
2018-06-22 03:38:56 +08:00
|
|
|
/// \p NumVGPRs are used.
|
2018-09-13 02:50:47 +08:00
|
|
|
unsigned getNumVGPRBlocks(const MCSubtargetInfo *STI, unsigned NumSGPRs);
|
2018-06-22 03:38:56 +08:00
|
|
|
|
2017-02-14 08:33:36 +08:00
|
|
|
} // end namespace IsaInfo
|
2017-02-08 22:05:23 +08:00
|
|
|
|
|
|
|
LLVM_READONLY
|
|
|
|
int16_t getNamedOperandIdx(uint16_t Opcode, uint16_t NamedIdx);
|
|
|
|
|
AMDGPU: Select MIMG instructions manually in SITargetLowering
Summary:
Having TableGen patterns for image intrinsics is hitting limitations:
for D16 we already have to manually pre-lower the packing of data
values, and we will have to do the same for A16 eventually.
Since there is already some custom C++ code anyway, it is arguably easier
to just do everything in C++, now that we can use the beefed-up generic
tables backend of TableGen to provide all the required metadata and map
intrinsics to corresponding opcodes. With this approach, all image
intrinsic lowering happens in SITargetLowering::lowerImage. That code is
dense due to all the cases that it handles, but it should still be easier
to follow than what we had before, by virtue of it all being done in a
single location, and by virtue of not relying on the TableGen pattern
magic that very few people really understand.
This means that we will have MachineSDNodes with MIMG instructions
during DAG combining, but that seems alright: previously we had
intrinsic nodes instead, but those are similarly opaque to the generic
CodeGen infrastructure, and the final pattern matching just did a 1:1
translation to machine instructions anyway. If anything, the fact that
we now merge the address words into a vector before DAG combine should
be an advantage.
Change-Id: I417f26bd88f54ce9781c1668acc01f3f99774de6
Reviewers: arsenm, rampitec, rtaylor, tstellar
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D48017
llvm-svn: 335228
2018-06-21 21:36:57 +08:00
|
|
|
struct MIMGBaseOpcodeInfo {
|
|
|
|
MIMGBaseOpcode BaseOpcode;
|
|
|
|
bool Store;
|
|
|
|
bool Atomic;
|
|
|
|
bool AtomicX2;
|
|
|
|
bool Sampler;
|
[AMDGPU] Add support for TFE/LWE in image intrinsics. 2nd try
TFE and LWE support requires extra result registers that are written in the
event of a failure in order to detect that failure case.
The specific use-case that initiated these changes is sparse texture support.
This means that if image intrinsics are used with either option turned on, the
programmer must ensure that the return type can contain all of the expected
results. This can result in redundant registers since the vector size must be a
power-of-2.
This change takes roughly 6 parts:
1. Modify the instruction defs in tablegen to add new instruction variants that
can accomodate the extra return values.
2. Updates to lowerImage in SIISelLowering.cpp to accomodate setting TFE or LWE
(where the bulk of the work for these instruction types is now done)
3. Extra verification code to catch cases where intrinsics have been used but
insufficient return registers are used.
4. Modification to the adjustWritemask optimisation to account for TFE/LWE being
enabled (requires extra registers to be maintained for error return value).
5. An extra pass to zero initialize the error value return - this is because if
the error does not occur, the register is not written and thus must be zeroed
before use. Also added a new (on by default) option to ensure ALL return values
are zero-initialized that is required for sparse texture support.
6. Disable the inst_combine optimization in the presence of tfe/lwe (later TODO
for this to re-enable and handle correctly).
There's an additional fix now to avoid a dmask=0
For an image intrinsic with tfe where all result channels except tfe
were unused, I was getting an image instruction with dmask=0 and only a
single vgpr result for tfe. That is incorrect because the hardware
assumes there is at least one vgpr result, plus the one for tfe.
Fixed by forcing dmask to 1, which gives the desired two vgpr result
with tfe in the second one.
The TFE or LWE result is returned from the intrinsics using an aggregate
type. Look in the test code provided to see how this works, but in essence IR
code to invoke the intrinsic looks as follows:
%v = call {<4 x float>,i32} @llvm.amdgcn.image.load.1d.v4f32i32.i32(i32 15,
i32 %s, <8 x i32> %rsrc, i32 1, i32 0)
%v.vec = extractvalue {<4 x float>, i32} %v, 0
%v.err = extractvalue {<4 x float>, i32} %v, 1
This re-submit of the change also includes a slight modification in
SIISelLowering.cpp to work-around a compiler bug for the powerpc_le
platform that caused a buildbot failure on a previous submission.
Differential revision: https://reviews.llvm.org/D48826
Change-Id: If222bc03642e76cf98059a6bef5d5bffeda38dda
Work around for ppcle compiler bug
Change-Id: Ie284cf24b2271215be1b9dc95b485fd15000e32b
llvm-svn: 351054
2019-01-14 19:55:24 +08:00
|
|
|
bool Gather4;
|
AMDGPU: Select MIMG instructions manually in SITargetLowering
Summary:
Having TableGen patterns for image intrinsics is hitting limitations:
for D16 we already have to manually pre-lower the packing of data
values, and we will have to do the same for A16 eventually.
Since there is already some custom C++ code anyway, it is arguably easier
to just do everything in C++, now that we can use the beefed-up generic
tables backend of TableGen to provide all the required metadata and map
intrinsics to corresponding opcodes. With this approach, all image
intrinsic lowering happens in SITargetLowering::lowerImage. That code is
dense due to all the cases that it handles, but it should still be easier
to follow than what we had before, by virtue of it all being done in a
single location, and by virtue of not relying on the TableGen pattern
magic that very few people really understand.
This means that we will have MachineSDNodes with MIMG instructions
during DAG combining, but that seems alright: previously we had
intrinsic nodes instead, but those are similarly opaque to the generic
CodeGen infrastructure, and the final pattern matching just did a 1:1
translation to machine instructions anyway. If anything, the fact that
we now merge the address words into a vector before DAG combine should
be an advantage.
Change-Id: I417f26bd88f54ce9781c1668acc01f3f99774de6
Reviewers: arsenm, rampitec, rtaylor, tstellar
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D48017
llvm-svn: 335228
2018-06-21 21:36:57 +08:00
|
|
|
|
|
|
|
uint8_t NumExtraArgs;
|
|
|
|
bool Gradients;
|
|
|
|
bool Coordinates;
|
|
|
|
bool LodOrClampOrMip;
|
|
|
|
bool HasD16;
|
|
|
|
};
|
|
|
|
|
|
|
|
LLVM_READONLY
|
|
|
|
const MIMGBaseOpcodeInfo *getMIMGBaseOpcodeInfo(unsigned BaseOpcode);
|
|
|
|
|
|
|
|
struct MIMGDimInfo {
|
|
|
|
MIMGDim Dim;
|
|
|
|
uint8_t NumCoords;
|
|
|
|
uint8_t NumGradients;
|
|
|
|
bool DA;
|
|
|
|
};
|
|
|
|
|
|
|
|
LLVM_READONLY
|
|
|
|
const MIMGDimInfo *getMIMGDimInfo(unsigned Dim);
|
|
|
|
|
[AMDGPU] Optimize _L image intrinsic to _LZ when lod is zero
Summary:
Add _L to _LZ image intrinsic table mapping to table gen.
In ISelLowering check if image intrinsic has lod and if it's equal
to zero, if so remove lod and change opcode to equivalent mapped _LZ.
Change-Id: Ie24cd7e788e2195d846c7bd256151178cbb9ec71
Subscribers: arsenm, mehdi_amini, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, steven_wu, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D49483
llvm-svn: 338523
2018-08-01 20:12:01 +08:00
|
|
|
struct MIMGLZMappingInfo {
|
|
|
|
MIMGBaseOpcode L;
|
|
|
|
MIMGBaseOpcode LZ;
|
|
|
|
};
|
|
|
|
|
|
|
|
LLVM_READONLY
|
|
|
|
const MIMGLZMappingInfo *getMIMGLZMappingInfo(unsigned L);
|
|
|
|
|
AMDGPU: Select MIMG instructions manually in SITargetLowering
Summary:
Having TableGen patterns for image intrinsics is hitting limitations:
for D16 we already have to manually pre-lower the packing of data
values, and we will have to do the same for A16 eventually.
Since there is already some custom C++ code anyway, it is arguably easier
to just do everything in C++, now that we can use the beefed-up generic
tables backend of TableGen to provide all the required metadata and map
intrinsics to corresponding opcodes. With this approach, all image
intrinsic lowering happens in SITargetLowering::lowerImage. That code is
dense due to all the cases that it handles, but it should still be easier
to follow than what we had before, by virtue of it all being done in a
single location, and by virtue of not relying on the TableGen pattern
magic that very few people really understand.
This means that we will have MachineSDNodes with MIMG instructions
during DAG combining, but that seems alright: previously we had
intrinsic nodes instead, but those are similarly opaque to the generic
CodeGen infrastructure, and the final pattern matching just did a 1:1
translation to machine instructions anyway. If anything, the fact that
we now merge the address words into a vector before DAG combine should
be an advantage.
Change-Id: I417f26bd88f54ce9781c1668acc01f3f99774de6
Reviewers: arsenm, rampitec, rtaylor, tstellar
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D48017
llvm-svn: 335228
2018-06-21 21:36:57 +08:00
|
|
|
LLVM_READONLY
|
|
|
|
int getMIMGOpcode(unsigned BaseOpcode, unsigned MIMGEncoding,
|
|
|
|
unsigned VDataDwords, unsigned VAddrDwords);
|
|
|
|
|
2017-12-14 05:07:51 +08:00
|
|
|
LLVM_READONLY
|
2018-06-21 21:36:44 +08:00
|
|
|
int getMaskedMIMGOp(unsigned Opc, unsigned NewChannels);
|
AMDGPU: Turn D16 for MIMG instructions into a regular operand
Summary:
This allows us to reduce the number of different machine instruction
opcodes, which reduces the table sizes and helps flatten the TableGen
multiclass hierarchies.
We can do this because for each hardware MIMG opcode, we have a full set
of IMAGE_xxx_Vn_Vm machine instructions for all required sizes of vdata
and vaddr registers. Instead of having separate D16 machine instructions,
a packed D16 instructions loading e.g. 4 components can simply use the
same V2 opcode variant that non-D16 instructions use.
We still require a TSFlag for D16 buffer instructions, because the
D16-ness of buffer instructions is part of the opcode. Renaming the flag
should help avoid future confusion.
The one non-obvious code change is that for gather4 instructions, the
disassembler can no longer automatically decide whether to use a V2 or
a V4 variant. The existing logic which choose the correct variant for
other MIMG instruction is extended to cover gather4 as well.
As a bonus, some of the assembler error messages are now more helpful
(e.g., complaining about a wrong data size instead of a non-existing
instruction).
While we're at it, delete a whole bunch of dead legacy TableGen code.
Change-Id: I89b02c2841c06f95e662541433e597f5d4553978
Reviewers: arsenm, rampitec, kzhuravl, artem.tamazov, dp, rtaylor
Subscribers: wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D47434
llvm-svn: 335222
2018-06-21 21:36:01 +08:00
|
|
|
|
2018-12-13 00:15:21 +08:00
|
|
|
LLVM_READONLY
|
|
|
|
int getMUBUFBaseOpcode(unsigned Opc);
|
|
|
|
|
|
|
|
LLVM_READONLY
|
|
|
|
int getMUBUFOpcode(unsigned BaseOpc, unsigned Dwords);
|
|
|
|
|
|
|
|
LLVM_READONLY
|
|
|
|
int getMUBUFDwords(unsigned Opc);
|
|
|
|
|
|
|
|
LLVM_READONLY
|
|
|
|
bool getMUBUFHasVAddr(unsigned Opc);
|
|
|
|
|
|
|
|
LLVM_READONLY
|
|
|
|
bool getMUBUFHasSrsrc(unsigned Opc);
|
|
|
|
|
|
|
|
LLVM_READONLY
|
|
|
|
bool getMUBUFHasSoffset(unsigned Opc);
|
|
|
|
|
2017-12-14 05:07:51 +08:00
|
|
|
LLVM_READONLY
|
|
|
|
int getMCOpcode(uint16_t Opcode, unsigned Gen);
|
|
|
|
|
2015-06-27 05:58:31 +08:00
|
|
|
void initDefaultAMDKernelCodeT(amd_kernel_code_t &Header,
|
2018-09-13 02:50:47 +08:00
|
|
|
const MCSubtargetInfo *STI);
|
2015-12-03 11:34:32 +08:00
|
|
|
|
2018-06-22 03:38:56 +08:00
|
|
|
amdhsa::kernel_descriptor_t getDefaultAmdhsaKernelDescriptor();
|
|
|
|
|
2017-11-02 03:12:38 +08:00
|
|
|
bool isGroupSegment(const GlobalValue *GV);
|
|
|
|
bool isGlobalSegment(const GlobalValue *GV);
|
|
|
|
bool isReadOnlySegment(const GlobalValue *GV);
|
2015-12-03 01:00:42 +08:00
|
|
|
|
2016-10-21 02:12:38 +08:00
|
|
|
/// \returns True if constants should be emitted to .text section for given
|
|
|
|
/// target triple \p TT, false otherwise.
|
|
|
|
bool shouldEmitConstantsToTextSection(const Triple &TT);
|
|
|
|
|
2016-09-07 04:22:28 +08:00
|
|
|
/// \returns Integer value requested using \p F's \p Name attribute.
|
|
|
|
///
|
|
|
|
/// \returns \p Default if attribute is not present.
|
|
|
|
///
|
|
|
|
/// \returns \p Default and emits error if requested value cannot be converted
|
|
|
|
/// to integer.
|
2016-05-12 10:45:18 +08:00
|
|
|
int getIntegerAttribute(const Function &F, StringRef Name, int Default);
|
|
|
|
|
2016-09-07 04:22:28 +08:00
|
|
|
/// \returns A pair of integer values requested using \p F's \p Name attribute
|
|
|
|
/// in "first[,second]" format ("second" is optional unless \p OnlyFirstRequired
|
|
|
|
/// is false).
|
|
|
|
///
|
|
|
|
/// \returns \p Default if attribute is not present.
|
|
|
|
///
|
|
|
|
/// \returns \p Default and emits error if one of the requested values cannot be
|
|
|
|
/// converted to integer, or \p OnlyFirstRequired is false and "second" value is
|
|
|
|
/// not present.
|
|
|
|
std::pair<int, int> getIntegerPairAttribute(const Function &F,
|
|
|
|
StringRef Name,
|
|
|
|
std::pair<int, int> Default,
|
|
|
|
bool OnlyFirstRequired = false);
|
|
|
|
|
AMDGPU/InsertWaitcnts: Untangle some semi-global state
Summary:
Reduce the statefulness of the algorithm in two ways:
1. More clearly split generateWaitcntInstBefore into two phases: the
first one which determines the required wait, if any, without changing
the ScoreBrackets, and the second one which actually inserts the wait
and updates the brackets.
2. Communicate pre-existing s_waitcnt instructions using an argument to
generateWaitcntInstBefore instead of through the ScoreBrackets.
To simplify these changes, a Waitcnt structure is introduced which carries
the counts of an s_waitcnt instruction in decoded form.
There are some functional changes:
1. The FIXME for the VCCZ bug workaround was implemented: we only wait for
SMEM instructions as required instead of waiting on all counters.
2. We now properly track pre-existing waitcnt's in all cases, which leads
to less conservative waitcnts being emitted in some cases.
s_load_dword ...
s_waitcnt lgkmcnt(0) <-- pre-existing wait count
ds_read_b32 v0, ...
ds_read_b32 v1, ...
s_waitcnt lgkmcnt(0) <-- this is too conservative
use(v0)
more code
use(v1)
This increases code size a bit, but the reduced latency should still be a
win in basically all cases. The worst code size regressions in my shader-db
are:
WORST REGRESSIONS - Code Size
Before After Delta Percentage
1724 1736 12 0.70 % shaders/private/f1-2015/1334.shader_test [0]
2276 2284 8 0.35 % shaders/private/f1-2015/1306.shader_test [0]
4632 4640 8 0.17 % shaders/private/ue4_elemental/62.shader_test [0]
2376 2384 8 0.34 % shaders/private/f1-2015/1308.shader_test [0]
3284 3292 8 0.24 % shaders/private/talos_principle/1955.shader_test [0]
Reviewers: msearles, rampitec, scott.linder, kanarayan
Subscribers: arsenm, kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits, hakzsam
Differential Revision: https://reviews.llvm.org/D54226
llvm-svn: 347848
2018-11-29 19:06:06 +08:00
|
|
|
/// Represents the counter values to wait for in an s_waitcnt instruction.
|
|
|
|
///
|
|
|
|
/// Large values (including the maximum possible integer) can be used to
|
|
|
|
/// represent "don't care" waits.
|
|
|
|
struct Waitcnt {
|
|
|
|
unsigned VmCnt = ~0u;
|
|
|
|
unsigned ExpCnt = ~0u;
|
|
|
|
unsigned LgkmCnt = ~0u;
|
|
|
|
|
|
|
|
Waitcnt() {}
|
|
|
|
Waitcnt(unsigned VmCnt, unsigned ExpCnt, unsigned LgkmCnt)
|
|
|
|
: VmCnt(VmCnt), ExpCnt(ExpCnt), LgkmCnt(LgkmCnt) {}
|
|
|
|
|
|
|
|
static Waitcnt allZero() { return Waitcnt(0, 0, 0); }
|
|
|
|
|
|
|
|
bool dominates(const Waitcnt &Other) const {
|
|
|
|
return VmCnt <= Other.VmCnt && ExpCnt <= Other.ExpCnt &&
|
|
|
|
LgkmCnt <= Other.LgkmCnt;
|
|
|
|
}
|
|
|
|
|
|
|
|
Waitcnt combined(const Waitcnt &Other) const {
|
|
|
|
return Waitcnt(std::min(VmCnt, Other.VmCnt), std::min(ExpCnt, Other.ExpCnt),
|
|
|
|
std::min(LgkmCnt, Other.LgkmCnt));
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2016-10-12 02:58:22 +08:00
|
|
|
/// \returns Vmcnt bit mask for given isa \p Version.
|
2018-09-13 02:50:47 +08:00
|
|
|
unsigned getVmcntBitMask(const IsaVersion &Version);
|
2016-10-01 01:01:40 +08:00
|
|
|
|
2016-10-12 02:58:22 +08:00
|
|
|
/// \returns Expcnt bit mask for given isa \p Version.
|
2018-09-13 02:50:47 +08:00
|
|
|
unsigned getExpcntBitMask(const IsaVersion &Version);
|
2016-10-01 01:01:40 +08:00
|
|
|
|
2016-10-12 02:58:22 +08:00
|
|
|
/// \returns Lgkmcnt bit mask for given isa \p Version.
|
2018-09-13 02:50:47 +08:00
|
|
|
unsigned getLgkmcntBitMask(const IsaVersion &Version);
|
2017-02-08 22:05:23 +08:00
|
|
|
|
|
|
|
/// \returns Waitcnt bit mask for given isa \p Version.
|
2018-09-13 02:50:47 +08:00
|
|
|
unsigned getWaitcntBitMask(const IsaVersion &Version);
|
2016-10-01 01:01:40 +08:00
|
|
|
|
2016-10-12 02:58:22 +08:00
|
|
|
/// \returns Decoded Vmcnt from given \p Waitcnt for given isa \p Version.
|
2018-09-13 02:50:47 +08:00
|
|
|
unsigned decodeVmcnt(const IsaVersion &Version, unsigned Waitcnt);
|
2016-10-01 01:01:40 +08:00
|
|
|
|
2016-10-12 02:58:22 +08:00
|
|
|
/// \returns Decoded Expcnt from given \p Waitcnt for given isa \p Version.
|
2018-09-13 02:50:47 +08:00
|
|
|
unsigned decodeExpcnt(const IsaVersion &Version, unsigned Waitcnt);
|
2016-10-12 02:58:22 +08:00
|
|
|
|
|
|
|
/// \returns Decoded Lgkmcnt from given \p Waitcnt for given isa \p Version.
|
2018-09-13 02:50:47 +08:00
|
|
|
unsigned decodeLgkmcnt(const IsaVersion &Version, unsigned Waitcnt);
|
2016-10-12 02:58:22 +08:00
|
|
|
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Decodes Vmcnt, Expcnt and Lgkmcnt from given \p Waitcnt for given isa
|
2016-10-12 02:58:22 +08:00
|
|
|
/// \p Version, and writes decoded values into \p Vmcnt, \p Expcnt and
|
|
|
|
/// \p Lgkmcnt respectively.
|
|
|
|
///
|
|
|
|
/// \details \p Vmcnt, \p Expcnt and \p Lgkmcnt are decoded as follows:
|
2017-02-19 02:29:53 +08:00
|
|
|
/// \p Vmcnt = \p Waitcnt[3:0] (pre-gfx9 only)
|
|
|
|
/// \p Vmcnt = \p Waitcnt[3:0] | \p Waitcnt[15:14] (gfx9+ only)
|
2016-10-12 02:58:22 +08:00
|
|
|
/// \p Expcnt = \p Waitcnt[6:4]
|
|
|
|
/// \p Lgkmcnt = \p Waitcnt[11:8]
|
2018-09-13 02:50:47 +08:00
|
|
|
void decodeWaitcnt(const IsaVersion &Version, unsigned Waitcnt,
|
2016-10-12 02:58:22 +08:00
|
|
|
unsigned &Vmcnt, unsigned &Expcnt, unsigned &Lgkmcnt);
|
|
|
|
|
AMDGPU/InsertWaitcnts: Untangle some semi-global state
Summary:
Reduce the statefulness of the algorithm in two ways:
1. More clearly split generateWaitcntInstBefore into two phases: the
first one which determines the required wait, if any, without changing
the ScoreBrackets, and the second one which actually inserts the wait
and updates the brackets.
2. Communicate pre-existing s_waitcnt instructions using an argument to
generateWaitcntInstBefore instead of through the ScoreBrackets.
To simplify these changes, a Waitcnt structure is introduced which carries
the counts of an s_waitcnt instruction in decoded form.
There are some functional changes:
1. The FIXME for the VCCZ bug workaround was implemented: we only wait for
SMEM instructions as required instead of waiting on all counters.
2. We now properly track pre-existing waitcnt's in all cases, which leads
to less conservative waitcnts being emitted in some cases.
s_load_dword ...
s_waitcnt lgkmcnt(0) <-- pre-existing wait count
ds_read_b32 v0, ...
ds_read_b32 v1, ...
s_waitcnt lgkmcnt(0) <-- this is too conservative
use(v0)
more code
use(v1)
This increases code size a bit, but the reduced latency should still be a
win in basically all cases. The worst code size regressions in my shader-db
are:
WORST REGRESSIONS - Code Size
Before After Delta Percentage
1724 1736 12 0.70 % shaders/private/f1-2015/1334.shader_test [0]
2276 2284 8 0.35 % shaders/private/f1-2015/1306.shader_test [0]
4632 4640 8 0.17 % shaders/private/ue4_elemental/62.shader_test [0]
2376 2384 8 0.34 % shaders/private/f1-2015/1308.shader_test [0]
3284 3292 8 0.24 % shaders/private/talos_principle/1955.shader_test [0]
Reviewers: msearles, rampitec, scott.linder, kanarayan
Subscribers: arsenm, kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits, hakzsam
Differential Revision: https://reviews.llvm.org/D54226
llvm-svn: 347848
2018-11-29 19:06:06 +08:00
|
|
|
Waitcnt decodeWaitcnt(const IsaVersion &Version, unsigned Encoded);
|
|
|
|
|
2016-10-12 02:58:22 +08:00
|
|
|
/// \returns \p Waitcnt with encoded \p Vmcnt for given isa \p Version.
|
2018-09-13 02:50:47 +08:00
|
|
|
unsigned encodeVmcnt(const IsaVersion &Version, unsigned Waitcnt,
|
2017-02-08 22:05:23 +08:00
|
|
|
unsigned Vmcnt);
|
2016-10-12 02:58:22 +08:00
|
|
|
|
|
|
|
/// \returns \p Waitcnt with encoded \p Expcnt for given isa \p Version.
|
2018-09-13 02:50:47 +08:00
|
|
|
unsigned encodeExpcnt(const IsaVersion &Version, unsigned Waitcnt,
|
2017-02-08 22:05:23 +08:00
|
|
|
unsigned Expcnt);
|
2016-10-12 02:58:22 +08:00
|
|
|
|
|
|
|
/// \returns \p Waitcnt with encoded \p Lgkmcnt for given isa \p Version.
|
2018-09-13 02:50:47 +08:00
|
|
|
unsigned encodeLgkmcnt(const IsaVersion &Version, unsigned Waitcnt,
|
2017-02-08 22:05:23 +08:00
|
|
|
unsigned Lgkmcnt);
|
2016-10-12 02:58:22 +08:00
|
|
|
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Encodes \p Vmcnt, \p Expcnt and \p Lgkmcnt into Waitcnt for given isa
|
2016-10-12 02:58:22 +08:00
|
|
|
/// \p Version.
|
|
|
|
///
|
|
|
|
/// \details \p Vmcnt, \p Expcnt and \p Lgkmcnt are encoded as follows:
|
2017-02-19 02:29:53 +08:00
|
|
|
/// Waitcnt[3:0] = \p Vmcnt (pre-gfx9 only)
|
|
|
|
/// Waitcnt[3:0] = \p Vmcnt[3:0] (gfx9+ only)
|
|
|
|
/// Waitcnt[6:4] = \p Expcnt
|
|
|
|
/// Waitcnt[11:8] = \p Lgkmcnt
|
|
|
|
/// Waitcnt[15:14] = \p Vmcnt[5:4] (gfx9+ only)
|
2016-10-12 02:58:22 +08:00
|
|
|
///
|
|
|
|
/// \returns Waitcnt with encoded \p Vmcnt, \p Expcnt and \p Lgkmcnt for given
|
|
|
|
/// isa \p Version.
|
2018-09-13 02:50:47 +08:00
|
|
|
unsigned encodeWaitcnt(const IsaVersion &Version,
|
2016-10-12 02:58:22 +08:00
|
|
|
unsigned Vmcnt, unsigned Expcnt, unsigned Lgkmcnt);
|
2016-10-01 01:01:40 +08:00
|
|
|
|
AMDGPU/InsertWaitcnts: Untangle some semi-global state
Summary:
Reduce the statefulness of the algorithm in two ways:
1. More clearly split generateWaitcntInstBefore into two phases: the
first one which determines the required wait, if any, without changing
the ScoreBrackets, and the second one which actually inserts the wait
and updates the brackets.
2. Communicate pre-existing s_waitcnt instructions using an argument to
generateWaitcntInstBefore instead of through the ScoreBrackets.
To simplify these changes, a Waitcnt structure is introduced which carries
the counts of an s_waitcnt instruction in decoded form.
There are some functional changes:
1. The FIXME for the VCCZ bug workaround was implemented: we only wait for
SMEM instructions as required instead of waiting on all counters.
2. We now properly track pre-existing waitcnt's in all cases, which leads
to less conservative waitcnts being emitted in some cases.
s_load_dword ...
s_waitcnt lgkmcnt(0) <-- pre-existing wait count
ds_read_b32 v0, ...
ds_read_b32 v1, ...
s_waitcnt lgkmcnt(0) <-- this is too conservative
use(v0)
more code
use(v1)
This increases code size a bit, but the reduced latency should still be a
win in basically all cases. The worst code size regressions in my shader-db
are:
WORST REGRESSIONS - Code Size
Before After Delta Percentage
1724 1736 12 0.70 % shaders/private/f1-2015/1334.shader_test [0]
2276 2284 8 0.35 % shaders/private/f1-2015/1306.shader_test [0]
4632 4640 8 0.17 % shaders/private/ue4_elemental/62.shader_test [0]
2376 2384 8 0.34 % shaders/private/f1-2015/1308.shader_test [0]
3284 3292 8 0.24 % shaders/private/talos_principle/1955.shader_test [0]
Reviewers: msearles, rampitec, scott.linder, kanarayan
Subscribers: arsenm, kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits, hakzsam
Differential Revision: https://reviews.llvm.org/D54226
llvm-svn: 347848
2018-11-29 19:06:06 +08:00
|
|
|
unsigned encodeWaitcnt(const IsaVersion &Version, const Waitcnt &Decoded);
|
|
|
|
|
2016-01-13 19:45:36 +08:00
|
|
|
unsigned getInitialPSInputAddr(const Function &F);
|
|
|
|
|
2017-04-12 06:29:24 +08:00
|
|
|
LLVM_READNONE
|
|
|
|
bool isShader(CallingConv::ID CC);
|
|
|
|
|
|
|
|
LLVM_READNONE
|
|
|
|
bool isCompute(CallingConv::ID CC);
|
|
|
|
|
|
|
|
LLVM_READNONE
|
|
|
|
bool isEntryFunctionCC(CallingConv::ID CC);
|
|
|
|
|
2017-04-12 06:29:28 +08:00
|
|
|
// FIXME: Remove this when calling conventions cleaned up
|
|
|
|
LLVM_READNONE
|
|
|
|
inline bool isKernel(CallingConv::ID CC) {
|
|
|
|
switch (CC) {
|
|
|
|
case CallingConv::AMDGPU_KERNEL:
|
|
|
|
case CallingConv::SPIR_KERNEL:
|
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
2015-12-16 00:26:16 +08:00
|
|
|
|
2018-01-10 22:22:19 +08:00
|
|
|
bool hasXNACK(const MCSubtargetInfo &STI);
|
2018-11-06 06:44:19 +08:00
|
|
|
bool hasSRAMECC(const MCSubtargetInfo &STI);
|
2018-02-05 20:45:43 +08:00
|
|
|
bool hasMIMG_R128(const MCSubtargetInfo &STI);
|
2018-02-05 22:18:53 +08:00
|
|
|
bool hasPackedD16(const MCSubtargetInfo &STI);
|
2018-02-05 20:45:43 +08:00
|
|
|
|
2015-12-22 02:44:27 +08:00
|
|
|
bool isSI(const MCSubtargetInfo &STI);
|
|
|
|
bool isCI(const MCSubtargetInfo &STI);
|
|
|
|
bool isVI(const MCSubtargetInfo &STI);
|
2017-05-23 18:08:55 +08:00
|
|
|
bool isGFX9(const MCSubtargetInfo &STI);
|
|
|
|
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Is Reg - scalar register
|
2017-05-23 18:08:55 +08:00
|
|
|
bool isSGPR(unsigned Reg, const MCRegisterInfo* TRI);
|
2015-12-22 02:44:27 +08:00
|
|
|
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Is there any intersection between registers
|
2017-06-21 22:41:34 +08:00
|
|
|
bool isRegIntersect(unsigned Reg0, unsigned Reg1, const MCRegisterInfo* TRI);
|
|
|
|
|
2015-12-22 02:44:27 +08:00
|
|
|
/// If \p Reg is a pseudo reg, return the correct hardware register given
|
|
|
|
/// \p STI otherwise return \p Reg.
|
|
|
|
unsigned getMCReg(unsigned Reg, const MCSubtargetInfo &STI);
|
|
|
|
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Convert hardware register \p Reg to a pseudo register
|
2017-03-03 22:31:06 +08:00
|
|
|
LLVM_READNONE
|
|
|
|
unsigned mc2PseudoReg(unsigned Reg);
|
|
|
|
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Can this operand also contain immediate values?
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 22:44:04 +08:00
|
|
|
bool isSISrcOperand(const MCInstrDesc &Desc, unsigned OpNo);
|
|
|
|
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Is this floating-point operand?
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 22:44:04 +08:00
|
|
|
bool isSISrcFPOperand(const MCInstrDesc &Desc, unsigned OpNo);
|
|
|
|
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Does this opearnd support only inlinable literals?
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 22:44:04 +08:00
|
|
|
bool isSISrcInlinableOperand(const MCInstrDesc &Desc, unsigned OpNo);
|
|
|
|
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Get the size in bits of a register from the register class \p RC.
|
2016-10-28 07:05:31 +08:00
|
|
|
unsigned getRegBitWidth(unsigned RCID);
|
|
|
|
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Get the size in bits of a register from the register class \p RC.
|
2016-10-20 01:40:36 +08:00
|
|
|
unsigned getRegBitWidth(const MCRegisterClass &RC);
|
|
|
|
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Get size of register operand
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 22:44:04 +08:00
|
|
|
unsigned getRegOperandSize(const MCRegisterInfo *MRI, const MCInstrDesc &Desc,
|
|
|
|
unsigned OpNo);
|
|
|
|
|
2016-12-10 08:39:12 +08:00
|
|
|
LLVM_READNONE
|
|
|
|
inline unsigned getOperandSize(const MCOperandInfo &OpInfo) {
|
|
|
|
switch (OpInfo.OperandType) {
|
|
|
|
case AMDGPU::OPERAND_REG_IMM_INT32:
|
|
|
|
case AMDGPU::OPERAND_REG_IMM_FP32:
|
|
|
|
case AMDGPU::OPERAND_REG_INLINE_C_INT32:
|
|
|
|
case AMDGPU::OPERAND_REG_INLINE_C_FP32:
|
|
|
|
return 4;
|
|
|
|
|
|
|
|
case AMDGPU::OPERAND_REG_IMM_INT64:
|
|
|
|
case AMDGPU::OPERAND_REG_IMM_FP64:
|
|
|
|
case AMDGPU::OPERAND_REG_INLINE_C_INT64:
|
|
|
|
case AMDGPU::OPERAND_REG_INLINE_C_FP64:
|
|
|
|
return 8;
|
|
|
|
|
|
|
|
case AMDGPU::OPERAND_REG_IMM_INT16:
|
|
|
|
case AMDGPU::OPERAND_REG_IMM_FP16:
|
|
|
|
case AMDGPU::OPERAND_REG_INLINE_C_INT16:
|
|
|
|
case AMDGPU::OPERAND_REG_INLINE_C_FP16:
|
2017-02-28 02:49:11 +08:00
|
|
|
case AMDGPU::OPERAND_REG_INLINE_C_V2INT16:
|
|
|
|
case AMDGPU::OPERAND_REG_INLINE_C_V2FP16:
|
2016-12-10 08:39:12 +08:00
|
|
|
return 2;
|
|
|
|
|
|
|
|
default:
|
|
|
|
llvm_unreachable("unhandled operand type");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
LLVM_READNONE
|
|
|
|
inline unsigned getOperandSize(const MCInstrDesc &Desc, unsigned OpNo) {
|
|
|
|
return getOperandSize(Desc.OpInfo[OpNo]);
|
|
|
|
}
|
|
|
|
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Is this literal inlinable
|
2016-12-06 06:26:17 +08:00
|
|
|
LLVM_READNONE
|
|
|
|
bool isInlinableLiteral64(int64_t Literal, bool HasInv2Pi);
|
|
|
|
|
|
|
|
LLVM_READNONE
|
|
|
|
bool isInlinableLiteral32(int32_t Literal, bool HasInv2Pi);
|
|
|
|
|
2016-12-10 08:39:12 +08:00
|
|
|
LLVM_READNONE
|
|
|
|
bool isInlinableLiteral16(int16_t Literal, bool HasInv2Pi);
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 22:44:04 +08:00
|
|
|
|
2017-02-28 02:49:11 +08:00
|
|
|
LLVM_READNONE
|
|
|
|
bool isInlinableLiteralV216(int32_t Literal, bool HasInv2Pi);
|
|
|
|
|
2017-07-27 04:39:42 +08:00
|
|
|
bool isArgPassedInSGPR(const Argument *Arg);
|
2017-01-28 02:41:14 +08:00
|
|
|
|
|
|
|
/// \returns The encoding that will be used for \p ByteOffset in the SMRD
|
|
|
|
/// offset field.
|
|
|
|
int64_t getSMRDEncodedOffset(const MCSubtargetInfo &ST, int64_t ByteOffset);
|
|
|
|
|
|
|
|
/// \returns true if this offset is small enough to fit in the SMRD
|
|
|
|
/// offset field. \p ByteOffset should be the offset in bytes and
|
|
|
|
/// not the encoded offset.
|
|
|
|
bool isLegalSMRDImmOffset(const MCSubtargetInfo &ST, int64_t ByteOffset);
|
|
|
|
|
[AMDGPU] New buffer intrinsics
Summary:
This commit adds new intrinsics
llvm.amdgcn.raw.buffer.load
llvm.amdgcn.raw.buffer.load.format
llvm.amdgcn.raw.buffer.load.format.d16
llvm.amdgcn.struct.buffer.load
llvm.amdgcn.struct.buffer.load.format
llvm.amdgcn.struct.buffer.load.format.d16
llvm.amdgcn.raw.buffer.store
llvm.amdgcn.raw.buffer.store.format
llvm.amdgcn.raw.buffer.store.format.d16
llvm.amdgcn.struct.buffer.store
llvm.amdgcn.struct.buffer.store.format
llvm.amdgcn.struct.buffer.store.format.d16
llvm.amdgcn.raw.buffer.atomic.*
llvm.amdgcn.struct.buffer.atomic.*
with the following changes from the llvm.amdgcn.buffer.*
intrinsics:
* there are separate raw and struct versions: raw does not have an
index arg and sets idxen=0 in the instruction, and struct always sets
idxen=1 in the instruction even if the index is 0, to allow for the
fact that gfx9 does bounds checking differently depending on whether
idxen is set;
* there is a combined cachepolicy arg (glc+slc)
* there are now only two offset args: one for the offset that is
included in bounds checking and swizzling, to be split between the
instruction's voffset and immoffset fields, and one for the offset
that is excluded from bounds checking and swizzling, to go into the
instruction's soffset field.
The AMDISD::BUFFER_* SD nodes always have an index operand, all three
offset operands, combined cachepolicy operand, and an extra idxen
operand.
The obsolescent llvm.amdgcn.buffer.* intrinsics continue to work.
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, t-tye, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D50306
Change-Id: If897ea7dc34fcbf4d5496e98cc99a934f62fc205
llvm-svn: 340269
2018-08-21 19:07:10 +08:00
|
|
|
bool splitMUBUFOffset(uint32_t Imm, uint32_t &SOffset, uint32_t &ImmOffset,
|
AMDGPU: Divergence-driven selection of scalar buffer load intrinsics
Summary:
Moving SMRD to VMEM in SIFixSGPRCopies is rather bad for performance if
the load is really uniform. So select the scalar load intrinsics directly
to either VMEM or SMRD buffer loads based on divergence analysis.
If an offset happens to end up in a VGPR -- either because a floating
point calculation was involved, or due to other remaining deficiencies
in SIFixSGPRCopies -- we use v_readfirstlane.
There is some unrelated churn in tests since we now select MUBUF offsets
in a unified way with non-scalar buffer loads.
Change-Id: I170e6816323beb1348677b358c9d380865cd1a19
Reviewers: arsenm, alex-t, rampitec, tpr
Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D53283
llvm-svn: 348050
2018-12-01 06:55:38 +08:00
|
|
|
const GCNSubtarget *Subtarget, uint32_t Align = 4);
|
[AMDGPU] New buffer intrinsics
Summary:
This commit adds new intrinsics
llvm.amdgcn.raw.buffer.load
llvm.amdgcn.raw.buffer.load.format
llvm.amdgcn.raw.buffer.load.format.d16
llvm.amdgcn.struct.buffer.load
llvm.amdgcn.struct.buffer.load.format
llvm.amdgcn.struct.buffer.load.format.d16
llvm.amdgcn.raw.buffer.store
llvm.amdgcn.raw.buffer.store.format
llvm.amdgcn.raw.buffer.store.format.d16
llvm.amdgcn.struct.buffer.store
llvm.amdgcn.struct.buffer.store.format
llvm.amdgcn.struct.buffer.store.format.d16
llvm.amdgcn.raw.buffer.atomic.*
llvm.amdgcn.struct.buffer.atomic.*
with the following changes from the llvm.amdgcn.buffer.*
intrinsics:
* there are separate raw and struct versions: raw does not have an
index arg and sets idxen=0 in the instruction, and struct always sets
idxen=1 in the instruction even if the index is 0, to allow for the
fact that gfx9 does bounds checking differently depending on whether
idxen is set;
* there is a combined cachepolicy arg (glc+slc)
* there are now only two offset args: one for the offset that is
included in bounds checking and swizzling, to be split between the
instruction's voffset and immoffset fields, and one for the offset
that is excluded from bounds checking and swizzling, to go into the
instruction's soffset field.
The AMDISD::BUFFER_* SD nodes always have an index operand, all three
offset operands, combined cachepolicy operand, and an extra idxen
operand.
The obsolescent llvm.amdgcn.buffer.* intrinsics continue to work.
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, t-tye, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D50306
Change-Id: If897ea7dc34fcbf4d5496e98cc99a934f62fc205
llvm-svn: 340269
2018-08-21 19:07:10 +08:00
|
|
|
|
2018-03-05 23:12:21 +08:00
|
|
|
/// \returns true if the intrinsic is divergent
|
|
|
|
bool isIntrinsicSourceOfDivergence(unsigned IntrID);
|
|
|
|
|
2015-06-27 05:15:07 +08:00
|
|
|
} // end namespace AMDGPU
|
|
|
|
} // end namespace llvm
|
|
|
|
|
2017-02-14 08:33:36 +08:00
|
|
|
#endif // LLVM_LIB_TARGET_AMDGPU_UTILS_AMDGPUBASEINFO_H
|