2016-01-26 12:49:22 +08:00
|
|
|
//===-- AMDGPU.td - AMDGPU Tablegen files --------*- tablegen -*-===//
|
2012-12-12 05:25:42 +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
|
2012-12-12 05:25:42 +08:00
|
|
|
//
|
2016-01-26 12:49:22 +08:00
|
|
|
//===------------------------------------------------------------===//
|
2012-12-12 05:25:42 +08:00
|
|
|
|
2018-06-21 21:36:44 +08:00
|
|
|
include "llvm/TableGen/SearchableTable.td"
|
2014-06-14 00:38:59 +08:00
|
|
|
include "llvm/Target/Target.td"
|
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
|
|
|
include "AMDGPUFeatures.td"
|
2012-12-12 05:25:42 +08:00
|
|
|
|
2019-08-01 11:57:42 +08:00
|
|
|
def p0 : PtrValueType<i64, 0>;
|
|
|
|
|
def p1 : PtrValueType<i64, 1>;
|
|
|
|
|
def p2 : PtrValueType<i32, 2>;
|
|
|
|
|
def p3 : PtrValueType<i32, 3>;
|
|
|
|
|
def p4 : PtrValueType<i64, 4>;
|
|
|
|
|
def p5 : PtrValueType<i32, 5>;
|
|
|
|
|
def p6 : PtrValueType<i32, 6>;
|
|
|
|
|
|
|
|
|
|
|
2018-11-30 22:21:56 +08:00
|
|
|
class BoolToList<bit Value> {
|
|
|
|
|
list<int> ret = !if(Value, [1]<int>, []<int>);
|
|
|
|
|
}
|
|
|
|
|
|
2016-01-26 12:49:22 +08:00
|
|
|
//===------------------------------------------------------------===//
|
|
|
|
|
// Subtarget Features (device properties)
|
|
|
|
|
//===------------------------------------------------------------===//
|
2013-11-19 03:43:33 +08:00
|
|
|
|
2015-01-30 03:34:25 +08:00
|
|
|
def FeatureFastFMAF32 : SubtargetFeature<"fast-fmaf",
|
2016-01-26 12:49:22 +08:00
|
|
|
"FastFMAF32",
|
|
|
|
|
"true",
|
|
|
|
|
"Assuming f32 fma is at least as fast as mul + add"
|
|
|
|
|
>;
|
2015-01-30 03:34:25 +08:00
|
|
|
|
2018-08-16 03:45:04 +08:00
|
|
|
def FeatureFastDenormalF32 : SubtargetFeature<"fast-denormal-f32",
|
|
|
|
|
"FastDenormalF32",
|
|
|
|
|
"true",
|
|
|
|
|
"Enabling denormals does not cause f32 instructions to run at f64 rates"
|
|
|
|
|
>;
|
|
|
|
|
|
2018-02-05 20:45:43 +08:00
|
|
|
def FeatureMIMG_R128 : SubtargetFeature<"mimg-r128",
|
|
|
|
|
"MIMG_R128",
|
|
|
|
|
"true",
|
|
|
|
|
"Support 128-bit texture resources"
|
|
|
|
|
>;
|
|
|
|
|
|
2016-01-19 05:13:50 +08:00
|
|
|
def HalfRate64Ops : SubtargetFeature<"half-rate-64-ops",
|
2016-01-26 12:49:22 +08:00
|
|
|
"HalfRate64Ops",
|
|
|
|
|
"true",
|
|
|
|
|
"Most fp64 instructions are half rate instead of quarter"
|
|
|
|
|
>;
|
2014-07-15 07:40:49 +08:00
|
|
|
|
2014-09-15 23:41:53 +08:00
|
|
|
def FeatureFlatAddressSpace : SubtargetFeature<"flat-address-space",
|
2016-01-26 12:49:22 +08:00
|
|
|
"FlatAddressSpace",
|
|
|
|
|
"true",
|
|
|
|
|
"Support flat address space"
|
|
|
|
|
>;
|
2014-09-15 23:41:53 +08:00
|
|
|
|
2017-05-11 05:19:05 +08:00
|
|
|
def FeatureFlatInstOffsets : SubtargetFeature<"flat-inst-offsets",
|
|
|
|
|
"FlatInstOffsets",
|
|
|
|
|
"true",
|
|
|
|
|
"Flat instructions have immediate offset addressing mode"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureFlatGlobalInsts : SubtargetFeature<"flat-global-insts",
|
|
|
|
|
"FlatGlobalInsts",
|
|
|
|
|
"true",
|
|
|
|
|
"Have global_* flat memory instructions"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureFlatScratchInsts : SubtargetFeature<"flat-scratch-insts",
|
|
|
|
|
"FlatScratchInsts",
|
|
|
|
|
"true",
|
|
|
|
|
"Have scratch_* flat memory instructions"
|
|
|
|
|
>;
|
|
|
|
|
|
2019-04-25 01:03:15 +08:00
|
|
|
def FeatureScalarFlatScratchInsts : SubtargetFeature<"scalar-flat-scratch-insts",
|
|
|
|
|
"ScalarFlatScratchInsts",
|
|
|
|
|
"true",
|
|
|
|
|
"Have s_scratch_* flat memory instructions"
|
|
|
|
|
>;
|
|
|
|
|
|
2017-07-21 01:42:47 +08:00
|
|
|
def FeatureAddNoCarryInsts : SubtargetFeature<"add-no-carry-insts",
|
|
|
|
|
"AddNoCarryInsts",
|
|
|
|
|
"true",
|
|
|
|
|
"Have VALU add/sub instructions without carry out"
|
|
|
|
|
>;
|
|
|
|
|
|
2016-07-02 07:03:44 +08:00
|
|
|
def FeatureUnalignedBufferAccess : SubtargetFeature<"unaligned-buffer-access",
|
|
|
|
|
"UnalignedBufferAccess",
|
|
|
|
|
"true",
|
2020-11-11 22:33:55 +08:00
|
|
|
"Hardware supports unaligned global loads and stores"
|
2016-07-02 07:03:44 +08:00
|
|
|
>;
|
|
|
|
|
|
2017-02-10 10:15:29 +08:00
|
|
|
def FeatureTrapHandler: SubtargetFeature<"trap-handler",
|
|
|
|
|
"TrapHandler",
|
|
|
|
|
"true",
|
|
|
|
|
"Trap handler support"
|
|
|
|
|
>;
|
|
|
|
|
|
2016-10-15 02:10:39 +08:00
|
|
|
def FeatureUnalignedScratchAccess : SubtargetFeature<"unaligned-scratch-access",
|
|
|
|
|
"UnalignedScratchAccess",
|
|
|
|
|
"true",
|
|
|
|
|
"Support unaligned scratch loads and stores"
|
|
|
|
|
>;
|
|
|
|
|
|
2020-08-21 17:29:32 +08:00
|
|
|
def FeatureUnalignedDSAccess : SubtargetFeature<"unaligned-ds-access",
|
|
|
|
|
"UnalignedDSAccess",
|
|
|
|
|
"true",
|
2020-11-11 22:33:55 +08:00
|
|
|
"Hardware supports unaligned local and region loads and stores"
|
2020-08-21 17:29:32 +08:00
|
|
|
>;
|
|
|
|
|
|
2017-02-19 02:29:53 +08:00
|
|
|
def FeatureApertureRegs : SubtargetFeature<"aperture-regs",
|
|
|
|
|
"HasApertureRegs",
|
|
|
|
|
"true",
|
|
|
|
|
"Has Memory Aperture Base and Size Registers"
|
|
|
|
|
>;
|
|
|
|
|
|
2017-10-25 15:00:51 +08:00
|
|
|
def FeatureMadMixInsts : SubtargetFeature<"mad-mix-insts",
|
|
|
|
|
"HasMadMixInsts",
|
|
|
|
|
"true",
|
|
|
|
|
"Has v_mad_mix_f32, v_mad_mixlo_f16, v_mad_mixhi_f16 instructions"
|
|
|
|
|
>;
|
|
|
|
|
|
2018-05-01 03:08:16 +08:00
|
|
|
def FeatureFmaMixInsts : SubtargetFeature<"fma-mix-insts",
|
|
|
|
|
"HasFmaMixInsts",
|
|
|
|
|
"true",
|
|
|
|
|
"Has v_fma_mix_f32, v_fma_mixlo_f16, v_fma_mixhi_f16 instructions"
|
|
|
|
|
>;
|
|
|
|
|
|
2019-05-16 22:48:34 +08:00
|
|
|
def FeatureDoesNotSupportXNACK : SubtargetFeature<"no-xnack-support",
|
|
|
|
|
"DoesNotSupportXNACK",
|
|
|
|
|
"true",
|
|
|
|
|
"Hardware does not support XNACK"
|
|
|
|
|
>;
|
|
|
|
|
|
2016-12-10 03:49:54 +08:00
|
|
|
// XNACK is disabled if SH_MEM_CONFIG.ADDRESS_MODE = GPUVM on chips that support
|
|
|
|
|
// XNACK. The current default kernel driver setting is:
|
|
|
|
|
// - graphics ring: XNACK disabled
|
|
|
|
|
// - compute ring: XNACK enabled
|
|
|
|
|
//
|
|
|
|
|
// If XNACK is enabled, the VMEM latency can be worse.
|
|
|
|
|
// If XNACK is disabled, the 2 SGPRs can be used for general purposes.
|
2016-01-05 07:35:53 +08:00
|
|
|
def FeatureXNACK : SubtargetFeature<"xnack",
|
2016-01-26 12:49:22 +08:00
|
|
|
"EnableXNACK",
|
|
|
|
|
"true",
|
|
|
|
|
"Enable XNACK support"
|
|
|
|
|
>;
|
2015-01-21 03:33:04 +08:00
|
|
|
|
2019-04-25 01:03:15 +08:00
|
|
|
def FeatureCuMode : SubtargetFeature<"cumode",
|
|
|
|
|
"EnableCuMode",
|
|
|
|
|
"true",
|
|
|
|
|
"Enable CU wavefront execution mode"
|
|
|
|
|
>;
|
|
|
|
|
|
2015-03-09 23:48:09 +08:00
|
|
|
def FeatureSGPRInitBug : SubtargetFeature<"sgpr-init-bug",
|
2016-01-26 12:49:22 +08:00
|
|
|
"SGPRInitBug",
|
|
|
|
|
"true",
|
2017-08-07 02:13:23 +08:00
|
|
|
"VI SGPR initialization bug requiring a fixed SGPR allocation size"
|
2016-01-26 12:49:22 +08:00
|
|
|
>;
|
2016-01-21 12:28:34 +08:00
|
|
|
|
2019-04-25 01:03:15 +08:00
|
|
|
def FeatureLdsMisalignedBug : SubtargetFeature<"lds-misaligned-bug",
|
|
|
|
|
"LDSMisalignedBug",
|
|
|
|
|
"true",
|
2020-09-09 17:28:36 +08:00
|
|
|
"Some GFX10 bug with multi-dword LDS and flat access that is not naturally aligned in WGP mode"
|
2019-04-25 01:03:15 +08:00
|
|
|
>;
|
|
|
|
|
|
2019-08-24 06:09:58 +08:00
|
|
|
def FeatureMFMAInlineLiteralBug : SubtargetFeature<"mfma-inline-literal-bug",
|
|
|
|
|
"HasMFMAInlineLiteralBug",
|
|
|
|
|
"true",
|
|
|
|
|
"MFMA cannot use inline literal as SrcC"
|
|
|
|
|
>;
|
|
|
|
|
|
2019-04-25 01:03:15 +08:00
|
|
|
def FeatureVcmpxPermlaneHazard : SubtargetFeature<"vcmpx-permlane-hazard",
|
|
|
|
|
"HasVcmpxPermlaneHazard",
|
|
|
|
|
"true",
|
|
|
|
|
"TODO: describe me"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureVMEMtoScalarWriteHazard : SubtargetFeature<"vmem-to-scalar-write-hazard",
|
|
|
|
|
"HasVMEMtoScalarWriteHazard",
|
|
|
|
|
"true",
|
|
|
|
|
"VMEM instruction followed by scalar writing to EXEC mask, M0 or SGPR leads to incorrect execution."
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureSMEMtoVectorWriteHazard : SubtargetFeature<"smem-to-vector-write-hazard",
|
|
|
|
|
"HasSMEMtoVectorWriteHazard",
|
|
|
|
|
"true",
|
|
|
|
|
"s_load_dword followed by v_cmp page faults"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureInstFwdPrefetchBug : SubtargetFeature<"inst-fwd-prefetch-bug",
|
|
|
|
|
"HasInstFwdPrefetchBug",
|
|
|
|
|
"true",
|
|
|
|
|
"S_INST_PREFETCH instruction causes shader to hang"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureVcmpxExecWARHazard : SubtargetFeature<"vcmpx-exec-war-hazard",
|
|
|
|
|
"HasVcmpxExecWARHazard",
|
|
|
|
|
"true",
|
|
|
|
|
"V_CMPX WAR hazard on EXEC (V_CMPX issue ONLY)"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureLdsBranchVmemWARHazard : SubtargetFeature<"lds-branch-vmem-war-hazard",
|
|
|
|
|
"HasLdsBranchVmemWARHazard",
|
|
|
|
|
"true",
|
|
|
|
|
"Switching between LDS and VMEM-tex not waiting VM_VSRC=0"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureNSAtoVMEMBug : SubtargetFeature<"nsa-to-vmem-bug",
|
|
|
|
|
"HasNSAtoVMEMBug",
|
|
|
|
|
"true",
|
|
|
|
|
"MIMG-NSA followed by VMEM fail if EXEC_LO or EXEC_HI equals zero"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureFlatSegmentOffsetBug : SubtargetFeature<"flat-segment-offset-bug",
|
|
|
|
|
"HasFlatSegmentOffsetBug",
|
|
|
|
|
"true",
|
|
|
|
|
"GFX10 bug, inst_offset ignored in flat segment"
|
|
|
|
|
>;
|
|
|
|
|
|
2019-06-27 01:34:57 +08:00
|
|
|
def FeatureOffset3fBug : SubtargetFeature<"offset-3f-bug",
|
|
|
|
|
"HasOffset3fBug",
|
|
|
|
|
"true",
|
|
|
|
|
"Branch offset of 3f hardware bug"
|
|
|
|
|
>;
|
|
|
|
|
|
[AMDGPU] Implement hardware bug workaround for image instructions
Summary:
This implements a workaround for a hardware bug in gfx8 and gfx9,
where register usage is not estimated correctly for image_store and
image_gather4 instructions when D16 is used.
Change-Id: I4e30744da6796acac53a9b5ad37ac1c2035c8899
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, kerbowa, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81172
2020-04-04 05:37:51 +08:00
|
|
|
def FeatureImageStoreD16Bug : SubtargetFeature<"image-store-d16-bug",
|
|
|
|
|
"HasImageStoreD16Bug",
|
|
|
|
|
"true",
|
|
|
|
|
"Image Store D16 hardware bug"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureImageGather4D16Bug : SubtargetFeature<"image-gather4-d16-bug",
|
|
|
|
|
"HasImageGather4D16Bug",
|
|
|
|
|
"true",
|
|
|
|
|
"Image Gather4 D16 hardware bug"
|
|
|
|
|
>;
|
|
|
|
|
|
2015-05-26 00:15:54 +08:00
|
|
|
class SubtargetFeatureLDSBankCount <int Value> : SubtargetFeature <
|
2016-01-26 12:49:22 +08:00
|
|
|
"ldsbankcount"#Value,
|
|
|
|
|
"LDSBankCount",
|
|
|
|
|
!cast<string>(Value),
|
|
|
|
|
"The number of LDS banks per compute unit."
|
|
|
|
|
>;
|
2015-05-26 00:15:54 +08:00
|
|
|
|
|
|
|
|
def FeatureLDSBankCount16 : SubtargetFeatureLDSBankCount<16>;
|
|
|
|
|
def FeatureLDSBankCount32 : SubtargetFeatureLDSBankCount<32>;
|
|
|
|
|
|
2015-04-08 09:09:26 +08:00
|
|
|
def FeatureGCN3Encoding : SubtargetFeature<"gcn3-encoding",
|
2016-01-26 12:49:22 +08:00
|
|
|
"GCN3Encoding",
|
|
|
|
|
"true",
|
|
|
|
|
"Encoding format for VI"
|
|
|
|
|
>;
|
2015-04-24 03:33:54 +08:00
|
|
|
|
|
|
|
|
def FeatureCIInsts : SubtargetFeature<"ci-insts",
|
2016-01-26 12:49:22 +08:00
|
|
|
"CIInsts",
|
|
|
|
|
"true",
|
2017-10-03 04:31:18 +08:00
|
|
|
"Additional instructions for CI+"
|
2016-01-26 12:49:22 +08:00
|
|
|
>;
|
|
|
|
|
|
2019-04-06 02:24:34 +08:00
|
|
|
def FeatureGFX8Insts : SubtargetFeature<"gfx8-insts",
|
|
|
|
|
"GFX8Insts",
|
2018-08-07 15:28:46 +08:00
|
|
|
"true",
|
2019-04-06 02:24:34 +08:00
|
|
|
"Additional instructions for GFX8+"
|
2018-08-07 15:28:46 +08:00
|
|
|
>;
|
|
|
|
|
|
2017-02-19 03:12:26 +08:00
|
|
|
def FeatureGFX9Insts : SubtargetFeature<"gfx9-insts",
|
|
|
|
|
"GFX9Insts",
|
|
|
|
|
"true",
|
2017-10-03 04:31:18 +08:00
|
|
|
"Additional instructions for GFX9+"
|
2017-02-19 03:12:26 +08:00
|
|
|
>;
|
|
|
|
|
|
2019-04-25 01:03:15 +08:00
|
|
|
def FeatureGFX10Insts : SubtargetFeature<"gfx10-insts",
|
|
|
|
|
"GFX10Insts",
|
|
|
|
|
"true",
|
|
|
|
|
"Additional instructions for GFX10+"
|
|
|
|
|
>;
|
|
|
|
|
|
2020-06-16 05:10:39 +08:00
|
|
|
def FeatureGFX10_3Insts : SubtargetFeature<"gfx10-3-insts",
|
|
|
|
|
"GFX10_3Insts",
|
|
|
|
|
"true",
|
|
|
|
|
"Additional instructions for GFX10.3"
|
|
|
|
|
>;
|
|
|
|
|
|
2019-04-06 02:24:34 +08:00
|
|
|
def FeatureGFX7GFX8GFX9Insts : SubtargetFeature<"gfx7-gfx8-gfx9-insts",
|
|
|
|
|
"GFX7GFX8GFX9Insts",
|
|
|
|
|
"true",
|
|
|
|
|
"Instructions shared in GFX7, GFX8, GFX9"
|
|
|
|
|
>;
|
|
|
|
|
|
2016-02-27 16:53:55 +08:00
|
|
|
def FeatureSMemRealTime : SubtargetFeature<"s-memrealtime",
|
|
|
|
|
"HasSMemRealTime",
|
2016-02-27 16:53:46 +08:00
|
|
|
"true",
|
2016-02-27 16:53:55 +08:00
|
|
|
"Has s_memrealtime instruction"
|
|
|
|
|
>;
|
|
|
|
|
|
2016-10-29 12:05:06 +08:00
|
|
|
def FeatureInv2PiInlineImm : SubtargetFeature<"inv-2pi-inline-imm",
|
|
|
|
|
"HasInv2PiInlineImm",
|
|
|
|
|
"true",
|
|
|
|
|
"Has 1 / (2 * pi) as inline immediate"
|
|
|
|
|
>;
|
|
|
|
|
|
2016-02-27 16:53:55 +08:00
|
|
|
def Feature16BitInsts : SubtargetFeature<"16-bit-insts",
|
|
|
|
|
"Has16BitInsts",
|
|
|
|
|
"true",
|
|
|
|
|
"Has i16/f16 instructions"
|
2016-02-27 16:53:46 +08:00
|
|
|
>;
|
|
|
|
|
|
2017-02-28 02:49:11 +08:00
|
|
|
def FeatureVOP3P : SubtargetFeature<"vop3p",
|
|
|
|
|
"HasVOP3PInsts",
|
|
|
|
|
"true",
|
|
|
|
|
"Has VOP3P packed instructions"
|
|
|
|
|
>;
|
|
|
|
|
|
2016-10-13 02:00:51 +08:00
|
|
|
def FeatureMovrel : SubtargetFeature<"movrel",
|
|
|
|
|
"HasMovrel",
|
|
|
|
|
"true",
|
|
|
|
|
"Has v_movrel*_b32 instructions"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureVGPRIndexMode : SubtargetFeature<"vgpr-index-mode",
|
|
|
|
|
"HasVGPRIndexMode",
|
|
|
|
|
"true",
|
|
|
|
|
"Has VGPR mode register indexing"
|
|
|
|
|
>;
|
|
|
|
|
|
2016-10-29 05:55:15 +08:00
|
|
|
def FeatureScalarStores : SubtargetFeature<"scalar-stores",
|
|
|
|
|
"HasScalarStores",
|
|
|
|
|
"true",
|
|
|
|
|
"Has store scalar memory instructions"
|
|
|
|
|
>;
|
|
|
|
|
|
2018-04-03 00:10:25 +08:00
|
|
|
def FeatureScalarAtomics : SubtargetFeature<"scalar-atomics",
|
|
|
|
|
"HasScalarAtomics",
|
|
|
|
|
"true",
|
|
|
|
|
"Has atomic scalar memory instructions"
|
|
|
|
|
>;
|
|
|
|
|
|
2017-01-20 18:01:25 +08:00
|
|
|
def FeatureSDWA : SubtargetFeature<"sdwa",
|
|
|
|
|
"HasSDWA",
|
|
|
|
|
"true",
|
|
|
|
|
"Support SDWA (Sub-DWORD Addressing) extension"
|
|
|
|
|
>;
|
|
|
|
|
|
2017-06-22 14:26:41 +08:00
|
|
|
def FeatureSDWAOmod : SubtargetFeature<"sdwa-omod",
|
|
|
|
|
"HasSDWAOmod",
|
|
|
|
|
"true",
|
|
|
|
|
"Support OMod with SDWA (Sub-DWORD Addressing) extension"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureSDWAScalar : SubtargetFeature<"sdwa-scalar",
|
|
|
|
|
"HasSDWAScalar",
|
|
|
|
|
"true",
|
|
|
|
|
"Support scalar register with SDWA (Sub-DWORD Addressing) extension"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureSDWASdst : SubtargetFeature<"sdwa-sdst",
|
|
|
|
|
"HasSDWASdst",
|
|
|
|
|
"true",
|
|
|
|
|
"Support scalar dst for VOPC with SDWA (Sub-DWORD Addressing) extension"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureSDWAMac : SubtargetFeature<"sdwa-mav",
|
|
|
|
|
"HasSDWAMac",
|
|
|
|
|
"true",
|
|
|
|
|
"Support v_mac_f32/f16 with SDWA (Sub-DWORD Addressing) extension"
|
|
|
|
|
>;
|
|
|
|
|
|
[AMDGPU] SDWA: several fixes for V_CVT and VOPC instructions
Summary:
1. Instruction V_CVT_U32_F32 allow omod operand (see SIInstrInfo.td:1435). In fact this operand shouldn't be allowed here. This fix checks if SDWA pseudo instruction has OMod operand and then copy it.
2. There were several problems with support of VOPC instructions in SDWA peephole pass.
Reviewers: tstellar, arsenm, vpykhtin, airlied, kzhuravl
Subscribers: wdng, nhaehnle, yaxunl, dstuttard, tpr, sarnex, t-tye
Differential Revision: https://reviews.llvm.org/D34626
llvm-svn: 306413
2017-06-27 23:02:23 +08:00
|
|
|
def FeatureSDWAOutModsVOPC : SubtargetFeature<"sdwa-out-mods-vopc",
|
|
|
|
|
"HasSDWAOutModsVOPC",
|
2017-06-22 14:26:41 +08:00
|
|
|
"true",
|
|
|
|
|
"Support clamp for VOPC with SDWA (Sub-DWORD Addressing) extension"
|
|
|
|
|
>;
|
|
|
|
|
|
2017-01-20 18:01:25 +08:00
|
|
|
def FeatureDPP : SubtargetFeature<"dpp",
|
|
|
|
|
"HasDPP",
|
|
|
|
|
"true",
|
|
|
|
|
"Support DPP (Data Parallel Primitives) extension"
|
|
|
|
|
>;
|
|
|
|
|
|
2019-06-13 02:02:41 +08:00
|
|
|
// DPP8 allows arbitrary cross-lane swizzling withing groups of 8 lanes.
|
|
|
|
|
def FeatureDPP8 : SubtargetFeature<"dpp8",
|
|
|
|
|
"HasDPP8",
|
|
|
|
|
"true",
|
|
|
|
|
"Support DPP8 (Data Parallel Primitives) extension"
|
|
|
|
|
>;
|
|
|
|
|
|
2018-08-28 23:07:30 +08:00
|
|
|
def FeatureR128A16 : SubtargetFeature<"r128-a16",
|
|
|
|
|
"HasR128A16",
|
|
|
|
|
"true",
|
2020-01-29 17:04:36 +08:00
|
|
|
"Support gfx9-style A16 for 16-bit coordinates/gradients/lod/clamp/mip image operands, where a16 is aliased with r128"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureGFX10A16 : SubtargetFeature<"a16",
|
|
|
|
|
"HasGFX10A16",
|
|
|
|
|
"true",
|
|
|
|
|
"Support gfx10-style A16 for 16-bit coordinates/gradients/lod/clamp/mip image operands"
|
2018-08-28 23:07:30 +08:00
|
|
|
>;
|
|
|
|
|
|
2020-03-25 15:38:22 +08:00
|
|
|
def FeatureG16 : SubtargetFeature<"g16",
|
|
|
|
|
"HasG16",
|
|
|
|
|
"true",
|
|
|
|
|
"Support G16 for 16-bit gradient image operands"
|
|
|
|
|
>;
|
|
|
|
|
|
2019-04-25 01:03:15 +08:00
|
|
|
def FeatureNSAEncoding : SubtargetFeature<"nsa-encoding",
|
|
|
|
|
"HasNSAEncoding",
|
|
|
|
|
"true",
|
|
|
|
|
"Support NSA encoding for image instructions"
|
|
|
|
|
>;
|
|
|
|
|
|
2020-06-16 05:10:39 +08:00
|
|
|
def FeatureGFX10_BEncoding : SubtargetFeature<"gfx10_b-encoding",
|
|
|
|
|
"GFX10_BEncoding",
|
|
|
|
|
"true",
|
|
|
|
|
"Encoding format GFX10_B"
|
|
|
|
|
>;
|
|
|
|
|
|
2017-08-16 21:51:56 +08:00
|
|
|
def FeatureIntClamp : SubtargetFeature<"int-clamp-insts",
|
|
|
|
|
"HasIntClamp",
|
|
|
|
|
"true",
|
|
|
|
|
"Support clamp for integer destination"
|
|
|
|
|
>;
|
|
|
|
|
|
2018-01-13 05:12:19 +08:00
|
|
|
def FeatureUnpackedD16VMem : SubtargetFeature<"unpacked-d16-vmem",
|
|
|
|
|
"HasUnpackedD16VMem",
|
|
|
|
|
"true",
|
|
|
|
|
"Has unpacked d16 vmem instructions"
|
|
|
|
|
>;
|
|
|
|
|
|
2018-05-01 03:08:16 +08:00
|
|
|
def FeatureDLInsts : SubtargetFeature<"dl-insts",
|
|
|
|
|
"HasDLInsts",
|
|
|
|
|
"true",
|
2019-01-10 11:25:20 +08:00
|
|
|
"Has v_fmac_f32 and v_xnor_b32 instructions"
|
|
|
|
|
>;
|
|
|
|
|
|
2019-02-09 08:34:21 +08:00
|
|
|
def FeatureDot1Insts : SubtargetFeature<"dot1-insts",
|
|
|
|
|
"HasDot1Insts",
|
2019-01-10 11:25:20 +08:00
|
|
|
"true",
|
2019-02-09 08:34:21 +08:00
|
|
|
"Has v_dot4_i32_i8 and v_dot8_i32_i4 instructions"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureDot2Insts : SubtargetFeature<"dot2-insts",
|
|
|
|
|
"HasDot2Insts",
|
|
|
|
|
"true",
|
|
|
|
|
"Has v_dot2_f32_f16, v_dot2_i32_i16, v_dot2_u32_u16, v_dot4_u32_u8, v_dot8_u32_u4 instructions"
|
2018-05-01 03:08:16 +08:00
|
|
|
>;
|
|
|
|
|
|
2019-07-10 02:10:06 +08:00
|
|
|
def FeatureDot3Insts : SubtargetFeature<"dot3-insts",
|
|
|
|
|
"HasDot3Insts",
|
|
|
|
|
"true",
|
|
|
|
|
"Has v_dot8c_i32_i4 instruction"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureDot4Insts : SubtargetFeature<"dot4-insts",
|
|
|
|
|
"HasDot4Insts",
|
|
|
|
|
"true",
|
|
|
|
|
"Has v_dot2c_i32_i16 instruction"
|
|
|
|
|
>;
|
|
|
|
|
|
2019-06-14 08:33:31 +08:00
|
|
|
def FeatureDot5Insts : SubtargetFeature<"dot5-insts",
|
|
|
|
|
"HasDot5Insts",
|
|
|
|
|
"true",
|
|
|
|
|
"Has v_dot2c_f32_f16 instruction"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureDot6Insts : SubtargetFeature<"dot6-insts",
|
|
|
|
|
"HasDot6Insts",
|
|
|
|
|
"true",
|
|
|
|
|
"Has v_dot4c_i32_i8 instruction"
|
|
|
|
|
>;
|
|
|
|
|
|
2019-07-10 02:10:06 +08:00
|
|
|
def FeatureMAIInsts : SubtargetFeature<"mai-insts",
|
|
|
|
|
"HasMAIInsts",
|
|
|
|
|
"true",
|
|
|
|
|
"Has mAI instructions"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeaturePkFmacF16Inst : SubtargetFeature<"pk-fmac-f16-inst",
|
|
|
|
|
"HasPkFmacF16Inst",
|
|
|
|
|
"true",
|
|
|
|
|
"Has v_pk_fmac_f16 instruction"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureAtomicFaddInsts : SubtargetFeature<"atomic-fadd-insts",
|
|
|
|
|
"HasAtomicFaddInsts",
|
|
|
|
|
"true",
|
|
|
|
|
"Has buffer_atomic_add_f32, buffer_atomic_pk_add_f16, global_atomic_add_f32, "
|
2020-06-05 02:37:39 +08:00
|
|
|
"global_atomic_pk_add_f16 instructions",
|
|
|
|
|
[FeatureFlatGlobalInsts]
|
2019-07-10 02:10:06 +08:00
|
|
|
>;
|
|
|
|
|
|
2019-04-03 09:58:57 +08:00
|
|
|
def FeatureDoesNotSupportSRAMECC : SubtargetFeature<"no-sram-ecc-support",
|
|
|
|
|
"DoesNotSupportSRAMECC",
|
|
|
|
|
"true",
|
|
|
|
|
"Hardware does not support SRAM ECC"
|
|
|
|
|
>;
|
|
|
|
|
|
2018-11-06 06:44:19 +08:00
|
|
|
def FeatureSRAMECC : SubtargetFeature<"sram-ecc",
|
|
|
|
|
"EnableSRAMECC",
|
2018-05-05 04:06:57 +08:00
|
|
|
"true",
|
2018-11-06 06:44:19 +08:00
|
|
|
"Enable SRAM ECC"
|
2018-05-05 04:06:57 +08:00
|
|
|
>;
|
|
|
|
|
|
2019-04-25 01:03:15 +08:00
|
|
|
def FeatureNoSdstCMPX : SubtargetFeature<"no-sdst-cmpx",
|
|
|
|
|
"HasNoSdstCMPX",
|
|
|
|
|
"true",
|
|
|
|
|
"V_CMPX does not write VCC/SGPR in addition to EXEC"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureVscnt : SubtargetFeature<"vscnt",
|
|
|
|
|
"HasVscnt",
|
|
|
|
|
"true",
|
|
|
|
|
"Has separate store vscnt counter"
|
|
|
|
|
>;
|
|
|
|
|
|
2020-06-16 05:10:39 +08:00
|
|
|
def FeatureGetWaveIdInst : SubtargetFeature<"get-wave-id-inst",
|
|
|
|
|
"HasGetWaveIdInst",
|
|
|
|
|
"true",
|
|
|
|
|
"Has s_get_waveid_in_workgroup instruction"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureSMemTimeInst : SubtargetFeature<"s-memtime-inst",
|
|
|
|
|
"HasSMemTimeInst",
|
|
|
|
|
"true",
|
|
|
|
|
"Has s_memtime instruction"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureMadMacF32Insts : SubtargetFeature<"mad-mac-f32-insts",
|
|
|
|
|
"HasMadMacF32Insts",
|
|
|
|
|
"true",
|
|
|
|
|
"Has v_mad_f32/v_mac_f32/v_madak_f32/v_madmk_f32 instructions"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureDsSrc2Insts : SubtargetFeature<"ds-src2-insts",
|
|
|
|
|
"HasDsSrc2Insts",
|
|
|
|
|
"true",
|
|
|
|
|
"Has ds_*_src2 instructions"
|
|
|
|
|
>;
|
|
|
|
|
|
2019-04-25 01:03:15 +08:00
|
|
|
def FeatureRegisterBanking : SubtargetFeature<"register-banking",
|
|
|
|
|
"HasRegisterBanking",
|
|
|
|
|
"true",
|
|
|
|
|
"Has register banking"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureVOP3Literal : SubtargetFeature<"vop3-literal",
|
|
|
|
|
"HasVOP3Literal",
|
|
|
|
|
"true",
|
|
|
|
|
"Can use one literal in VOP3"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureNoDataDepHazard : SubtargetFeature<"no-data-dep-hazard",
|
|
|
|
|
"HasNoDataDepHazard",
|
|
|
|
|
"true",
|
|
|
|
|
"Does not need SW waitstates"
|
|
|
|
|
>;
|
|
|
|
|
|
2016-01-26 12:49:22 +08:00
|
|
|
//===------------------------------------------------------------===//
|
|
|
|
|
// Subtarget Features (options and debugging)
|
|
|
|
|
//===------------------------------------------------------------===//
|
|
|
|
|
|
2016-02-12 10:40:47 +08:00
|
|
|
class FeatureMaxPrivateElementSize<int size> : SubtargetFeature<
|
|
|
|
|
"max-private-element-size-"#size,
|
|
|
|
|
"MaxPrivateElementSize",
|
|
|
|
|
!cast<string>(size),
|
|
|
|
|
"Maximum private access size may be "#size
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureMaxPrivateElementSize4 : FeatureMaxPrivateElementSize<4>;
|
|
|
|
|
def FeatureMaxPrivateElementSize8 : FeatureMaxPrivateElementSize<8>;
|
|
|
|
|
def FeatureMaxPrivateElementSize16 : FeatureMaxPrivateElementSize<16>;
|
|
|
|
|
|
2016-01-26 12:49:22 +08:00
|
|
|
def FeatureDumpCode : SubtargetFeature <"DumpCode",
|
|
|
|
|
"DumpCode",
|
|
|
|
|
"true",
|
|
|
|
|
"Dump MachineInstrs in the CodeEmitter"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureDumpCodeLower : SubtargetFeature <"dumpcode",
|
|
|
|
|
"DumpCode",
|
|
|
|
|
"true",
|
|
|
|
|
"Dump MachineInstrs in the CodeEmitter"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
// XXX - This should probably be removed once enabled by default
|
|
|
|
|
def FeatureEnableLoadStoreOpt : SubtargetFeature <"load-store-opt",
|
|
|
|
|
"EnableLoadStoreOpt",
|
|
|
|
|
"true",
|
|
|
|
|
"Enable SI load/store optimizer pass"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
// Performance debugging feature. Allow using DS instruction immediate
|
|
|
|
|
// offsets even if the base pointer can't be proven to be base. On SI,
|
|
|
|
|
// base pointer values that won't give the same result as a 16-bit add
|
|
|
|
|
// are not safe to fold, but this will override the conservative test
|
|
|
|
|
// for the base pointer.
|
|
|
|
|
def FeatureEnableUnsafeDSOffsetFolding : SubtargetFeature <
|
|
|
|
|
"unsafe-ds-offset-folding",
|
|
|
|
|
"EnableUnsafeDSOffsetFolding",
|
|
|
|
|
"true",
|
|
|
|
|
"Force using DS instruction immediate offsets on SI"
|
|
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureEnableSIScheduler : SubtargetFeature<"si-scheduler",
|
|
|
|
|
"EnableSIScheduler",
|
|
|
|
|
"true",
|
|
|
|
|
"Enable SI Machine Scheduler"
|
|
|
|
|
>;
|
|
|
|
|
|
2018-04-11 06:48:23 +08:00
|
|
|
def FeatureEnableDS128 : SubtargetFeature<"enable-ds128",
|
|
|
|
|
"EnableDS128",
|
|
|
|
|
"true",
|
|
|
|
|
"Use ds_{read|write}_b128"
|
|
|
|
|
>;
|
|
|
|
|
|
[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
|
|
|
// Sparse texture support requires that all result registers are zeroed when
|
|
|
|
|
// PRTStrictNull is set to true. This feature is turned on for all architectures
|
|
|
|
|
// but is enabled as a feature in case there are situations where PRTStrictNull
|
|
|
|
|
// is disabled by the driver.
|
|
|
|
|
def FeatureEnablePRTStrictNull : SubtargetFeature<"enable-prt-strict-null",
|
|
|
|
|
"EnablePRTStrictNull",
|
|
|
|
|
"true",
|
|
|
|
|
"Enable zeroing of result registers for sparse texture fetches"
|
|
|
|
|
>;
|
|
|
|
|
|
2017-01-25 06:02:15 +08:00
|
|
|
// Unless +-flat-for-global is specified, turn on FlatForGlobal for
|
|
|
|
|
// all OS-es on VI and newer hardware to avoid assertion failures due
|
|
|
|
|
// to missing ADDR64 variants of MUBUF instructions.
|
|
|
|
|
// FIXME: moveToVALU should be able to handle converting addr64 MUBUF
|
|
|
|
|
// instructions.
|
|
|
|
|
|
2016-01-26 12:49:22 +08:00
|
|
|
def FeatureFlatForGlobal : SubtargetFeature<"flat-for-global",
|
|
|
|
|
"FlatForGlobal",
|
|
|
|
|
"true",
|
2017-01-28 01:42:26 +08:00
|
|
|
"Force to generate flat instruction for global"
|
2016-01-26 12:49:22 +08:00
|
|
|
>;
|
2015-04-24 03:33:54 +08:00
|
|
|
|
2017-06-03 01:40:26 +08:00
|
|
|
def FeatureAutoWaitcntBeforeBarrier : SubtargetFeature <
|
|
|
|
|
"auto-waitcnt-before-barrier",
|
|
|
|
|
"AutoWaitcntBeforeBarrier",
|
|
|
|
|
"true",
|
|
|
|
|
"Hardware automatically inserts waitcnt before barrier"
|
|
|
|
|
>;
|
|
|
|
|
|
2018-09-14 18:27:19 +08:00
|
|
|
def FeatureTrigReducedRange : SubtargetFeature<"trig-reduced-range",
|
|
|
|
|
"HasTrigReducedRange",
|
|
|
|
|
"true",
|
|
|
|
|
"Requires use of fract on arguments to trig instructions"
|
|
|
|
|
>;
|
|
|
|
|
|
2020-11-11 22:33:55 +08:00
|
|
|
// Alignment enforcement is controlled by a configuration register:
|
|
|
|
|
// SH_MEM_CONFIG.alignment_mode
|
|
|
|
|
def FeatureUnalignedAccessMode : SubtargetFeature<"unaligned-access-mode",
|
|
|
|
|
"UnalignedAccessMode",
|
|
|
|
|
"true",
|
|
|
|
|
"Enable unaligned global, local and region loads and stores if the hardware"
|
|
|
|
|
" supports it"
|
|
|
|
|
>;
|
|
|
|
|
|
2015-04-24 03:33:54 +08:00
|
|
|
// Dummy feature used to disable assembler instructions.
|
|
|
|
|
def FeatureDisable : SubtargetFeature<"",
|
2016-01-26 12:49:22 +08:00
|
|
|
"FeatureDisable","true",
|
|
|
|
|
"Dummy feature to disable assembler instructions"
|
|
|
|
|
>;
|
2015-04-24 03:33:54 +08:00
|
|
|
|
2018-07-12 04:59:01 +08:00
|
|
|
class GCNSubtargetFeatureGeneration <string Value,
|
2019-04-03 08:01:03 +08:00
|
|
|
string FeatureName,
|
|
|
|
|
list<SubtargetFeature> Implies> :
|
|
|
|
|
SubtargetFeatureGeneration <Value, FeatureName, "GCNSubtarget", Implies>;
|
2013-06-08 04:37:48 +08:00
|
|
|
|
2018-07-12 04:59:01 +08:00
|
|
|
def FeatureSouthernIslands : GCNSubtargetFeatureGeneration<"SOUTHERN_ISLANDS",
|
2019-04-03 08:01:03 +08:00
|
|
|
"southern-islands",
|
2018-02-05 20:45:43 +08:00
|
|
|
[FeatureFP64, FeatureLocalMemorySize32768, FeatureMIMG_R128,
|
2020-06-16 05:10:39 +08:00
|
|
|
FeatureWavefrontSize64, FeatureSMemTimeInst, FeatureMadMacF32Insts,
|
|
|
|
|
FeatureDsSrc2Insts, FeatureLDSBankCount32, FeatureMovrel,
|
|
|
|
|
FeatureTrigReducedRange, FeatureDoesNotSupportSRAMECC,
|
|
|
|
|
FeatureDoesNotSupportXNACK]
|
2016-01-26 12:49:22 +08:00
|
|
|
>;
|
2013-06-08 04:37:48 +08:00
|
|
|
|
2018-07-12 04:59:01 +08:00
|
|
|
def FeatureSeaIslands : GCNSubtargetFeatureGeneration<"SEA_ISLANDS",
|
2019-04-03 08:01:03 +08:00
|
|
|
"sea-islands",
|
2018-02-05 20:45:43 +08:00
|
|
|
[FeatureFP64, FeatureLocalMemorySize65536, FeatureMIMG_R128,
|
2019-02-09 03:18:01 +08:00
|
|
|
FeatureWavefrontSize64, FeatureFlatAddressSpace,
|
2019-04-03 09:58:57 +08:00
|
|
|
FeatureCIInsts, FeatureMovrel, FeatureTrigReducedRange,
|
2020-06-16 05:10:39 +08:00
|
|
|
FeatureGFX7GFX8GFX9Insts, FeatureSMemTimeInst, FeatureMadMacF32Insts,
|
2020-11-11 22:33:55 +08:00
|
|
|
FeatureDsSrc2Insts, FeatureDoesNotSupportSRAMECC,
|
|
|
|
|
FeatureUnalignedBufferAccess]
|
2016-01-26 12:49:22 +08:00
|
|
|
>;
|
2014-12-07 20:18:57 +08:00
|
|
|
|
2018-07-12 04:59:01 +08:00
|
|
|
def FeatureVolcanicIslands : GCNSubtargetFeatureGeneration<"VOLCANIC_ISLANDS",
|
2019-04-03 08:01:03 +08:00
|
|
|
"volcanic-islands",
|
2018-02-05 20:45:43 +08:00
|
|
|
[FeatureFP64, FeatureLocalMemorySize65536, FeatureMIMG_R128,
|
2019-02-09 03:18:01 +08:00
|
|
|
FeatureWavefrontSize64, FeatureFlatAddressSpace,
|
2019-04-06 02:24:34 +08:00
|
|
|
FeatureGCN3Encoding, FeatureCIInsts, Feature16BitInsts,
|
2016-10-29 05:55:15 +08:00
|
|
|
FeatureSMemRealTime, FeatureVGPRIndexMode, FeatureMovrel,
|
2017-06-22 14:26:41 +08:00
|
|
|
FeatureScalarStores, FeatureInv2PiInlineImm,
|
2017-08-16 21:51:56 +08:00
|
|
|
FeatureSDWA, FeatureSDWAOutModsVOPC, FeatureSDWAMac, FeatureDPP,
|
2020-06-16 05:10:39 +08:00
|
|
|
FeatureIntClamp, FeatureTrigReducedRange, FeatureGFX8Insts,
|
|
|
|
|
FeatureGFX7GFX8GFX9Insts, FeatureSMemTimeInst, FeatureMadMacF32Insts,
|
2020-11-11 22:33:55 +08:00
|
|
|
FeatureDsSrc2Insts, FeatureDoesNotSupportSRAMECC, FeatureFastDenormalF32,
|
|
|
|
|
FeatureUnalignedBufferAccess
|
2016-02-27 16:53:55 +08:00
|
|
|
]
|
2016-01-26 12:49:22 +08:00
|
|
|
>;
|
2014-12-07 20:18:57 +08:00
|
|
|
|
2018-07-12 04:59:01 +08:00
|
|
|
def FeatureGFX9 : GCNSubtargetFeatureGeneration<"GFX9",
|
2019-04-03 08:01:03 +08:00
|
|
|
"gfx9",
|
2017-02-19 02:29:53 +08:00
|
|
|
[FeatureFP64, FeatureLocalMemorySize65536,
|
2019-02-09 03:18:01 +08:00
|
|
|
FeatureWavefrontSize64, FeatureFlatAddressSpace,
|
2019-04-06 02:24:34 +08:00
|
|
|
FeatureGCN3Encoding, FeatureCIInsts, Feature16BitInsts,
|
2017-02-19 02:29:53 +08:00
|
|
|
FeatureSMemRealTime, FeatureScalarStores, FeatureInv2PiInlineImm,
|
2017-04-22 03:57:53 +08:00
|
|
|
FeatureApertureRegs, FeatureGFX9Insts, FeatureVOP3P, FeatureVGPRIndexMode,
|
2017-08-16 21:51:56 +08:00
|
|
|
FeatureFastFMAF32, FeatureDPP, FeatureIntClamp,
|
2017-06-22 14:26:41 +08:00
|
|
|
FeatureSDWA, FeatureSDWAOmod, FeatureSDWAScalar, FeatureSDWASdst,
|
2017-07-21 01:42:47 +08:00
|
|
|
FeatureFlatInstOffsets, FeatureFlatGlobalInsts, FeatureFlatScratchInsts,
|
2019-04-06 02:24:34 +08:00
|
|
|
FeatureAddNoCarryInsts, FeatureGFX8Insts, FeatureGFX7GFX8GFX9Insts,
|
2018-08-16 03:45:04 +08:00
|
|
|
FeatureScalarFlatScratchInsts, FeatureScalarAtomics, FeatureR128A16,
|
2020-06-16 05:10:39 +08:00
|
|
|
FeatureSMemTimeInst, FeatureMadMacF32Insts, FeatureDsSrc2Insts,
|
2020-11-11 22:33:55 +08:00
|
|
|
FeatureFastDenormalF32, FeatureUnalignedBufferAccess,
|
|
|
|
|
FeatureUnalignedDSAccess
|
2020-06-16 05:10:39 +08:00
|
|
|
]
|
2019-04-25 01:03:15 +08:00
|
|
|
>;
|
|
|
|
|
|
|
|
|
|
def FeatureGFX10 : GCNSubtargetFeatureGeneration<"GFX10",
|
|
|
|
|
"gfx10",
|
|
|
|
|
[FeatureFP64, FeatureLocalMemorySize65536, FeatureMIMG_R128,
|
|
|
|
|
FeatureFlatAddressSpace,
|
|
|
|
|
FeatureCIInsts, Feature16BitInsts,
|
|
|
|
|
FeatureSMemRealTime, FeatureInv2PiInlineImm,
|
|
|
|
|
FeatureApertureRegs, FeatureGFX9Insts, FeatureGFX10Insts, FeatureVOP3P,
|
|
|
|
|
FeatureMovrel, FeatureFastFMAF32, FeatureDPP, FeatureIntClamp,
|
|
|
|
|
FeatureSDWA, FeatureSDWAOmod, FeatureSDWAScalar, FeatureSDWASdst,
|
|
|
|
|
FeatureFlatInstOffsets, FeatureFlatGlobalInsts, FeatureFlatScratchInsts,
|
|
|
|
|
FeatureAddNoCarryInsts, FeatureFmaMixInsts, FeatureGFX8Insts,
|
|
|
|
|
FeatureNoSdstCMPX, FeatureVscnt, FeatureRegisterBanking,
|
2019-07-10 06:42:24 +08:00
|
|
|
FeatureVOP3Literal, FeatureDPP8,
|
2020-01-29 17:04:36 +08:00
|
|
|
FeatureNoDataDepHazard, FeaturePkFmacF16Inst, FeatureDoesNotSupportSRAMECC,
|
2020-08-21 17:29:32 +08:00
|
|
|
FeatureGFX10A16, FeatureFastDenormalF32, FeatureG16,
|
2020-11-11 22:33:55 +08:00
|
|
|
FeatureUnalignedBufferAccess, FeatureUnalignedDSAccess
|
2017-02-19 02:29:53 +08:00
|
|
|
]
|
|
|
|
|
>;
|
|
|
|
|
|
2019-02-09 03:59:32 +08:00
|
|
|
class FeatureSet<list<SubtargetFeature> Features_> {
|
|
|
|
|
list<SubtargetFeature> Features = Features_;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
def FeatureISAVersion6_0_0 : FeatureSet<[FeatureSouthernIslands,
|
2017-06-26 11:01:36 +08:00
|
|
|
FeatureFastFMAF32,
|
2017-06-10 11:53:19 +08:00
|
|
|
HalfRate64Ops,
|
2018-11-15 10:32:43 +08:00
|
|
|
FeatureLDSBankCount32,
|
2020-10-15 01:03:37 +08:00
|
|
|
FeatureDoesNotSupportXNACK]>;
|
2017-06-10 11:53:19 +08:00
|
|
|
|
2019-02-09 03:59:32 +08:00
|
|
|
def FeatureISAVersion6_0_1 : FeatureSet<
|
2017-06-10 11:53:19 +08:00
|
|
|
[FeatureSouthernIslands,
|
2018-11-15 10:32:43 +08:00
|
|
|
FeatureLDSBankCount32,
|
2020-10-15 01:03:37 +08:00
|
|
|
FeatureDoesNotSupportXNACK]>;
|
2017-06-26 11:01:36 +08:00
|
|
|
|
2020-10-07 01:23:59 +08:00
|
|
|
def FeatureISAVersion6_0_2 : FeatureSet<
|
|
|
|
|
[FeatureSouthernIslands,
|
|
|
|
|
FeatureLDSBankCount32,
|
2020-10-15 01:03:37 +08:00
|
|
|
FeatureDoesNotSupportXNACK]>;
|
2020-10-07 01:23:59 +08:00
|
|
|
|
2019-02-09 03:59:32 +08:00
|
|
|
def FeatureISAVersion7_0_0 : FeatureSet<
|
2016-10-27 00:37:56 +08:00
|
|
|
[FeatureSeaIslands,
|
2018-11-15 10:32:43 +08:00
|
|
|
FeatureLDSBankCount32,
|
2020-10-15 01:03:37 +08:00
|
|
|
FeatureDoesNotSupportXNACK]>;
|
2016-11-01 08:55:14 +08:00
|
|
|
|
2019-02-09 03:59:32 +08:00
|
|
|
def FeatureISAVersion7_0_1 : FeatureSet<
|
2016-10-27 00:37:56 +08:00
|
|
|
[FeatureSeaIslands,
|
|
|
|
|
HalfRate64Ops,
|
|
|
|
|
FeatureLDSBankCount32,
|
2018-11-15 10:32:43 +08:00
|
|
|
FeatureFastFMAF32,
|
2020-10-15 01:03:37 +08:00
|
|
|
FeatureDoesNotSupportXNACK]>;
|
2016-11-01 08:55:14 +08:00
|
|
|
|
2019-02-09 03:59:32 +08:00
|
|
|
def FeatureISAVersion7_0_2 : FeatureSet<
|
2016-10-27 00:37:56 +08:00
|
|
|
[FeatureSeaIslands,
|
2018-02-28 05:46:15 +08:00
|
|
|
FeatureLDSBankCount16,
|
2018-11-15 10:32:43 +08:00
|
|
|
FeatureFastFMAF32,
|
2020-10-15 01:03:37 +08:00
|
|
|
FeatureDoesNotSupportXNACK]>;
|
2016-11-01 08:55:14 +08:00
|
|
|
|
2019-02-09 03:59:32 +08:00
|
|
|
def FeatureISAVersion7_0_3 : FeatureSet<
|
2017-06-10 11:53:19 +08:00
|
|
|
[FeatureSeaIslands,
|
2018-11-15 10:32:43 +08:00
|
|
|
FeatureLDSBankCount16,
|
2020-10-15 01:03:37 +08:00
|
|
|
FeatureDoesNotSupportXNACK]>;
|
2017-06-10 11:53:19 +08:00
|
|
|
|
2019-02-09 03:59:32 +08:00
|
|
|
def FeatureISAVersion7_0_4 : FeatureSet<
|
2017-12-09 04:52:28 +08:00
|
|
|
[FeatureSeaIslands,
|
2018-11-15 10:32:43 +08:00
|
|
|
FeatureLDSBankCount32,
|
2020-10-15 01:03:37 +08:00
|
|
|
FeatureDoesNotSupportXNACK]>;
|
2017-12-09 04:52:28 +08:00
|
|
|
|
2020-10-07 01:23:59 +08:00
|
|
|
def FeatureISAVersion7_0_5 : FeatureSet<
|
|
|
|
|
[FeatureSeaIslands,
|
|
|
|
|
FeatureLDSBankCount16,
|
2020-10-15 01:03:37 +08:00
|
|
|
FeatureDoesNotSupportXNACK]>;
|
2020-10-07 01:23:59 +08:00
|
|
|
|
2019-02-09 03:59:32 +08:00
|
|
|
def FeatureISAVersion8_0_1 : FeatureSet<
|
2016-10-27 00:37:56 +08:00
|
|
|
[FeatureVolcanicIslands,
|
2017-08-25 04:03:07 +08:00
|
|
|
FeatureFastFMAF32,
|
|
|
|
|
HalfRate64Ops,
|
2016-10-27 00:37:56 +08:00
|
|
|
FeatureLDSBankCount32,
|
2018-01-13 05:12:19 +08:00
|
|
|
FeatureXNACK,
|
2020-10-15 01:03:37 +08:00
|
|
|
FeatureUnpackedD16VMem]>;
|
2016-11-01 08:55:14 +08:00
|
|
|
|
2019-02-09 03:59:32 +08:00
|
|
|
def FeatureISAVersion8_0_2 : FeatureSet<
|
2016-10-27 00:37:56 +08:00
|
|
|
[FeatureVolcanicIslands,
|
|
|
|
|
FeatureLDSBankCount32,
|
2018-01-13 05:12:19 +08:00
|
|
|
FeatureSGPRInitBug,
|
2018-11-15 10:32:43 +08:00
|
|
|
FeatureUnpackedD16VMem,
|
2020-10-15 01:03:37 +08:00
|
|
|
FeatureDoesNotSupportXNACK]>;
|
2016-11-01 08:55:14 +08:00
|
|
|
|
2019-02-09 03:59:32 +08:00
|
|
|
def FeatureISAVersion8_0_3 : FeatureSet<
|
2016-10-27 00:37:56 +08:00
|
|
|
[FeatureVolcanicIslands,
|
2018-01-13 05:12:19 +08:00
|
|
|
FeatureLDSBankCount32,
|
2018-11-15 10:32:43 +08:00
|
|
|
FeatureUnpackedD16VMem,
|
2020-10-15 01:03:37 +08:00
|
|
|
FeatureDoesNotSupportXNACK]>;
|
2020-10-07 01:23:59 +08:00
|
|
|
|
|
|
|
|
def FeatureISAVersion8_0_5 : FeatureSet<
|
|
|
|
|
[FeatureVolcanicIslands,
|
|
|
|
|
FeatureLDSBankCount32,
|
|
|
|
|
FeatureSGPRInitBug,
|
|
|
|
|
FeatureUnpackedD16VMem,
|
2020-10-15 01:03:37 +08:00
|
|
|
FeatureDoesNotSupportXNACK]>;
|
2016-11-01 08:55:14 +08:00
|
|
|
|
2019-02-09 03:59:32 +08:00
|
|
|
def FeatureISAVersion8_1_0 : FeatureSet<
|
2016-10-27 00:37:56 +08:00
|
|
|
[FeatureVolcanicIslands,
|
|
|
|
|
FeatureLDSBankCount16,
|
2018-11-15 10:32:43 +08:00
|
|
|
FeatureXNACK,
|
[AMDGPU] Implement hardware bug workaround for image instructions
Summary:
This implements a workaround for a hardware bug in gfx8 and gfx9,
where register usage is not estimated correctly for image_store and
image_gather4 instructions when D16 is used.
Change-Id: I4e30744da6796acac53a9b5ad37ac1c2035c8899
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, kerbowa, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81172
2020-04-04 05:37:51 +08:00
|
|
|
FeatureImageStoreD16Bug,
|
|
|
|
|
FeatureImageGather4D16Bug]>;
|
2016-10-27 00:37:56 +08:00
|
|
|
|
2019-02-09 03:59:32 +08:00
|
|
|
def FeatureISAVersion9_0_0 : FeatureSet<
|
2017-06-10 11:53:19 +08:00
|
|
|
[FeatureGFX9,
|
2017-10-25 15:00:51 +08:00
|
|
|
FeatureMadMixInsts,
|
2018-11-15 10:32:43 +08:00
|
|
|
FeatureLDSBankCount32,
|
2019-05-16 22:48:34 +08:00
|
|
|
FeatureDoesNotSupportXNACK,
|
[AMDGPU] Implement hardware bug workaround for image instructions
Summary:
This implements a workaround for a hardware bug in gfx8 and gfx9,
where register usage is not estimated correctly for image_store and
image_gather4 instructions when D16 is used.
Change-Id: I4e30744da6796acac53a9b5ad37ac1c2035c8899
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, kerbowa, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81172
2020-04-04 05:37:51 +08:00
|
|
|
FeatureDoesNotSupportSRAMECC,
|
|
|
|
|
FeatureImageGather4D16Bug]>;
|
2017-06-10 11:53:19 +08:00
|
|
|
|
2019-02-09 03:59:32 +08:00
|
|
|
def FeatureISAVersion9_0_2 : FeatureSet<
|
2017-06-10 11:53:19 +08:00
|
|
|
[FeatureGFX9,
|
2017-10-25 15:00:51 +08:00
|
|
|
FeatureMadMixInsts,
|
2018-02-17 05:26:25 +08:00
|
|
|
FeatureLDSBankCount32,
|
2018-11-15 10:32:43 +08:00
|
|
|
FeatureXNACK,
|
2019-04-03 09:58:57 +08:00
|
|
|
FeatureDoesNotSupportSRAMECC,
|
[AMDGPU] Implement hardware bug workaround for image instructions
Summary:
This implements a workaround for a hardware bug in gfx8 and gfx9,
where register usage is not estimated correctly for image_store and
image_gather4 instructions when D16 is used.
Change-Id: I4e30744da6796acac53a9b5ad37ac1c2035c8899
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, kerbowa, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81172
2020-04-04 05:37:51 +08:00
|
|
|
FeatureImageGather4D16Bug]>;
|
2017-06-10 11:53:19 +08:00
|
|
|
|
2019-02-09 03:59:32 +08:00
|
|
|
def FeatureISAVersion9_0_4 : FeatureSet<
|
2018-05-01 03:08:16 +08:00
|
|
|
[FeatureGFX9,
|
|
|
|
|
FeatureLDSBankCount32,
|
2018-11-15 10:32:43 +08:00
|
|
|
FeatureFmaMixInsts,
|
2019-05-16 22:48:34 +08:00
|
|
|
FeatureDoesNotSupportXNACK,
|
2019-04-03 09:58:57 +08:00
|
|
|
FeatureDoesNotSupportSRAMECC,
|
[AMDGPU] Implement hardware bug workaround for image instructions
Summary:
This implements a workaround for a hardware bug in gfx8 and gfx9,
where register usage is not estimated correctly for image_store and
image_gather4 instructions when D16 is used.
Change-Id: I4e30744da6796acac53a9b5ad37ac1c2035c8899
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, kerbowa, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81172
2020-04-04 05:37:51 +08:00
|
|
|
FeatureImageGather4D16Bug]>;
|
2018-05-01 03:08:16 +08:00
|
|
|
|
2019-02-09 03:59:32 +08:00
|
|
|
def FeatureISAVersion9_0_6 : FeatureSet<
|
2018-05-01 03:08:16 +08:00
|
|
|
[FeatureGFX9,
|
|
|
|
|
HalfRate64Ops,
|
|
|
|
|
FeatureFmaMixInsts,
|
|
|
|
|
FeatureLDSBankCount32,
|
2018-11-06 06:44:19 +08:00
|
|
|
FeatureDLInsts,
|
2019-02-09 08:34:21 +08:00
|
|
|
FeatureDot1Insts,
|
|
|
|
|
FeatureDot2Insts,
|
2019-05-16 22:48:34 +08:00
|
|
|
FeatureDoesNotSupportXNACK,
|
[AMDGPU] Implement hardware bug workaround for image instructions
Summary:
This implements a workaround for a hardware bug in gfx8 and gfx9,
where register usage is not estimated correctly for image_store and
image_gather4 instructions when D16 is used.
Change-Id: I4e30744da6796acac53a9b5ad37ac1c2035c8899
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, kerbowa, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81172
2020-04-04 05:37:51 +08:00
|
|
|
FeatureImageGather4D16Bug]>;
|
2018-05-01 03:08:16 +08:00
|
|
|
|
2019-07-10 02:10:06 +08:00
|
|
|
def FeatureISAVersion9_0_8 : FeatureSet<
|
|
|
|
|
[FeatureGFX9,
|
|
|
|
|
HalfRate64Ops,
|
|
|
|
|
FeatureFmaMixInsts,
|
|
|
|
|
FeatureLDSBankCount32,
|
|
|
|
|
FeatureDLInsts,
|
|
|
|
|
FeatureDot1Insts,
|
|
|
|
|
FeatureDot2Insts,
|
|
|
|
|
FeatureDot3Insts,
|
|
|
|
|
FeatureDot4Insts,
|
|
|
|
|
FeatureDot5Insts,
|
|
|
|
|
FeatureDot6Insts,
|
|
|
|
|
FeatureMAIInsts,
|
|
|
|
|
FeaturePkFmacF16Inst,
|
|
|
|
|
FeatureAtomicFaddInsts,
|
|
|
|
|
FeatureSRAMECC,
|
2019-08-24 06:09:58 +08:00
|
|
|
FeatureMFMAInlineLiteralBug,
|
[AMDGPU] Implement hardware bug workaround for image instructions
Summary:
This implements a workaround for a hardware bug in gfx8 and gfx9,
where register usage is not estimated correctly for image_store and
image_gather4 instructions when D16 is used.
Change-Id: I4e30744da6796acac53a9b5ad37ac1c2035c8899
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, kerbowa, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81172
2020-04-04 05:37:51 +08:00
|
|
|
FeatureImageGather4D16Bug]>;
|
2019-07-10 02:10:06 +08:00
|
|
|
|
2019-02-09 03:59:32 +08:00
|
|
|
def FeatureISAVersion9_0_9 : FeatureSet<
|
2018-10-24 16:14:07 +08:00
|
|
|
[FeatureGFX9,
|
|
|
|
|
FeatureMadMixInsts,
|
|
|
|
|
FeatureLDSBankCount32,
|
2018-11-15 10:32:43 +08:00
|
|
|
FeatureXNACK,
|
[AMDGPU] Implement hardware bug workaround for image instructions
Summary:
This implements a workaround for a hardware bug in gfx8 and gfx9,
where register usage is not estimated correctly for image_store and
image_gather4 instructions when D16 is used.
Change-Id: I4e30744da6796acac53a9b5ad37ac1c2035c8899
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, kerbowa, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81172
2020-04-04 05:37:51 +08:00
|
|
|
FeatureImageGather4D16Bug]>;
|
2018-10-24 16:14:07 +08:00
|
|
|
|
2020-10-07 01:23:59 +08:00
|
|
|
def FeatureISAVersion9_0_C : FeatureSet<
|
|
|
|
|
[FeatureGFX9,
|
|
|
|
|
FeatureMadMixInsts,
|
|
|
|
|
FeatureLDSBankCount32,
|
|
|
|
|
FeatureXNACK,
|
|
|
|
|
FeatureImageGather4D16Bug]>;
|
|
|
|
|
|
2019-04-25 01:03:15 +08:00
|
|
|
// TODO: Organize more features into groups.
|
|
|
|
|
def FeatureGroup {
|
|
|
|
|
// Bugs present on gfx10.1.
|
|
|
|
|
list<SubtargetFeature> GFX10_1_Bugs = [
|
|
|
|
|
FeatureVcmpxPermlaneHazard,
|
|
|
|
|
FeatureVMEMtoScalarWriteHazard,
|
|
|
|
|
FeatureSMEMtoVectorWriteHazard,
|
|
|
|
|
FeatureInstFwdPrefetchBug,
|
|
|
|
|
FeatureVcmpxExecWARHazard,
|
|
|
|
|
FeatureLdsBranchVmemWARHazard,
|
|
|
|
|
FeatureNSAtoVMEMBug,
|
2019-06-27 01:34:57 +08:00
|
|
|
FeatureOffset3fBug,
|
2019-04-25 01:03:15 +08:00
|
|
|
FeatureFlatSegmentOffsetBug
|
|
|
|
|
];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
def FeatureISAVersion10_1_0 : FeatureSet<
|
|
|
|
|
!listconcat(FeatureGroup.GFX10_1_Bugs,
|
|
|
|
|
[FeatureGFX10,
|
|
|
|
|
FeatureLDSBankCount32,
|
|
|
|
|
FeatureDLInsts,
|
|
|
|
|
FeatureNSAEncoding,
|
2019-06-20 23:08:34 +08:00
|
|
|
FeatureWavefrontSize32,
|
2019-04-25 01:03:15 +08:00
|
|
|
FeatureScalarStores,
|
|
|
|
|
FeatureScalarAtomics,
|
|
|
|
|
FeatureScalarFlatScratchInsts,
|
2020-06-16 05:10:39 +08:00
|
|
|
FeatureGetWaveIdInst,
|
|
|
|
|
FeatureSMemTimeInst,
|
|
|
|
|
FeatureMadMacF32Insts,
|
|
|
|
|
FeatureDsSrc2Insts,
|
2019-04-25 01:03:15 +08:00
|
|
|
FeatureLdsMisalignedBug,
|
2020-10-15 01:03:37 +08:00
|
|
|
FeatureDoesNotSupportXNACK])>;
|
2019-04-25 01:03:15 +08:00
|
|
|
|
2019-06-14 08:33:31 +08:00
|
|
|
def FeatureISAVersion10_1_1 : FeatureSet<
|
|
|
|
|
!listconcat(FeatureGroup.GFX10_1_Bugs,
|
|
|
|
|
[FeatureGFX10,
|
|
|
|
|
FeatureLDSBankCount32,
|
|
|
|
|
FeatureDLInsts,
|
|
|
|
|
FeatureDot1Insts,
|
|
|
|
|
FeatureDot2Insts,
|
|
|
|
|
FeatureDot5Insts,
|
|
|
|
|
FeatureDot6Insts,
|
|
|
|
|
FeatureNSAEncoding,
|
2019-06-20 23:08:34 +08:00
|
|
|
FeatureWavefrontSize32,
|
2019-06-14 08:33:31 +08:00
|
|
|
FeatureScalarStores,
|
|
|
|
|
FeatureScalarAtomics,
|
|
|
|
|
FeatureScalarFlatScratchInsts,
|
2020-06-16 05:10:39 +08:00
|
|
|
FeatureGetWaveIdInst,
|
|
|
|
|
FeatureSMemTimeInst,
|
|
|
|
|
FeatureMadMacF32Insts,
|
|
|
|
|
FeatureDsSrc2Insts,
|
2020-09-09 17:28:36 +08:00
|
|
|
FeatureLdsMisalignedBug,
|
2020-10-15 01:03:37 +08:00
|
|
|
FeatureDoesNotSupportXNACK])>;
|
2019-06-14 08:33:31 +08:00
|
|
|
|
|
|
|
|
def FeatureISAVersion10_1_2 : FeatureSet<
|
|
|
|
|
!listconcat(FeatureGroup.GFX10_1_Bugs,
|
|
|
|
|
[FeatureGFX10,
|
|
|
|
|
FeatureLDSBankCount32,
|
|
|
|
|
FeatureDLInsts,
|
|
|
|
|
FeatureDot1Insts,
|
|
|
|
|
FeatureDot2Insts,
|
|
|
|
|
FeatureDot5Insts,
|
|
|
|
|
FeatureDot6Insts,
|
|
|
|
|
FeatureNSAEncoding,
|
2019-06-20 23:08:34 +08:00
|
|
|
FeatureWavefrontSize32,
|
2019-06-14 08:33:31 +08:00
|
|
|
FeatureScalarStores,
|
|
|
|
|
FeatureScalarAtomics,
|
|
|
|
|
FeatureScalarFlatScratchInsts,
|
2020-06-16 05:10:39 +08:00
|
|
|
FeatureGetWaveIdInst,
|
|
|
|
|
FeatureSMemTimeInst,
|
|
|
|
|
FeatureMadMacF32Insts,
|
|
|
|
|
FeatureDsSrc2Insts,
|
2019-06-14 08:33:31 +08:00
|
|
|
FeatureLdsMisalignedBug,
|
2020-10-15 01:03:37 +08:00
|
|
|
FeatureDoesNotSupportXNACK])>;
|
2019-06-14 08:33:31 +08:00
|
|
|
|
2020-06-16 05:10:39 +08:00
|
|
|
def FeatureISAVersion10_3_0 : FeatureSet<
|
|
|
|
|
[FeatureGFX10,
|
|
|
|
|
FeatureGFX10_BEncoding,
|
|
|
|
|
FeatureGFX10_3Insts,
|
|
|
|
|
FeatureLDSBankCount32,
|
|
|
|
|
FeatureDLInsts,
|
|
|
|
|
FeatureDot1Insts,
|
|
|
|
|
FeatureDot2Insts,
|
|
|
|
|
FeatureDot5Insts,
|
|
|
|
|
FeatureDot6Insts,
|
|
|
|
|
FeatureNSAEncoding,
|
|
|
|
|
FeatureWavefrontSize32,
|
2020-10-15 01:03:37 +08:00
|
|
|
FeatureDoesNotSupportXNACK]>;
|
2020-06-16 05:10:39 +08:00
|
|
|
|
2013-06-08 04:28:55 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2012-12-12 05:25:42 +08:00
|
|
|
|
|
|
|
|
def AMDGPUInstrInfo : InstrInfo {
|
|
|
|
|
let guessInstructionProperties = 1;
|
2015-02-18 10:15:32 +08:00
|
|
|
let noNamedPositionallyEncodedOperands = 1;
|
2012-12-12 05:25:42 +08:00
|
|
|
}
|
|
|
|
|
|
2014-11-14 22:08:00 +08:00
|
|
|
def AMDGPUAsmParser : AsmParser {
|
|
|
|
|
// Some of the R600 registers have the same name, so this crashes.
|
|
|
|
|
// For example T0_XYZW and T0_XY both have the asm name T0.
|
|
|
|
|
let ShouldEmitMatchRegisterName = 0;
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-27 22:42:48 +08:00
|
|
|
def AMDGPUAsmWriter : AsmWriter {
|
|
|
|
|
int PassSubtarget = 1;
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-09 17:37:51 +08:00
|
|
|
def AMDGPUAsmVariants {
|
|
|
|
|
string Default = "Default";
|
|
|
|
|
int Default_ID = 0;
|
|
|
|
|
string VOP3 = "VOP3";
|
|
|
|
|
int VOP3_ID = 1;
|
|
|
|
|
string SDWA = "SDWA";
|
|
|
|
|
int SDWA_ID = 2;
|
2017-05-23 18:08:55 +08:00
|
|
|
string SDWA9 = "SDWA9";
|
|
|
|
|
int SDWA9_ID = 3;
|
2016-09-09 17:37:51 +08:00
|
|
|
string DPP = "DPP";
|
2017-05-23 18:08:55 +08:00
|
|
|
int DPP_ID = 4;
|
2016-09-12 22:42:43 +08:00
|
|
|
string Disable = "Disable";
|
2017-05-23 18:08:55 +08:00
|
|
|
int Disable_ID = 5;
|
2016-09-09 17:37:51 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
def DefaultAMDGPUAsmParserVariant : AsmParserVariant {
|
|
|
|
|
let Variant = AMDGPUAsmVariants.Default_ID;
|
|
|
|
|
let Name = AMDGPUAsmVariants.Default;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
def VOP3AsmParserVariant : AsmParserVariant {
|
|
|
|
|
let Variant = AMDGPUAsmVariants.VOP3_ID;
|
|
|
|
|
let Name = AMDGPUAsmVariants.VOP3;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
def SDWAAsmParserVariant : AsmParserVariant {
|
|
|
|
|
let Variant = AMDGPUAsmVariants.SDWA_ID;
|
|
|
|
|
let Name = AMDGPUAsmVariants.SDWA;
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-23 18:08:55 +08:00
|
|
|
def SDWA9AsmParserVariant : AsmParserVariant {
|
|
|
|
|
let Variant = AMDGPUAsmVariants.SDWA9_ID;
|
|
|
|
|
let Name = AMDGPUAsmVariants.SDWA9;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2016-09-09 17:37:51 +08:00
|
|
|
def DPPAsmParserVariant : AsmParserVariant {
|
|
|
|
|
let Variant = AMDGPUAsmVariants.DPP_ID;
|
|
|
|
|
let Name = AMDGPUAsmVariants.DPP;
|
|
|
|
|
}
|
|
|
|
|
|
2012-12-12 05:25:42 +08:00
|
|
|
def AMDGPU : Target {
|
|
|
|
|
// Pull in Instruction Info:
|
|
|
|
|
let InstructionSet = AMDGPUInstrInfo;
|
2014-11-14 22:08:00 +08:00
|
|
|
let AssemblyParsers = [AMDGPUAsmParser];
|
2016-09-09 17:37:51 +08:00
|
|
|
let AssemblyParserVariants = [DefaultAMDGPUAsmParserVariant,
|
|
|
|
|
VOP3AsmParserVariant,
|
|
|
|
|
SDWAAsmParserVariant,
|
2017-05-23 18:08:55 +08:00
|
|
|
SDWA9AsmParserVariant,
|
2016-09-09 17:37:51 +08:00
|
|
|
DPPAsmParserVariant];
|
2016-09-27 22:42:48 +08:00
|
|
|
let AssemblyWriters = [AMDGPUAsmWriter];
|
[MachineOperand][Target] MachineOperand::isRenamable semantics changes
Summary:
Add a target option AllowRegisterRenaming that is used to opt in to
post-register-allocation renaming of registers. This is set to 0 by
default, which causes the hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq
fields of all opcodes to be set to 1, causing
MachineOperand::isRenamable to always return false.
Set the AllowRegisterRenaming flag to 1 for all in-tree targets that
have lit tests that were effected by enabling COPY forwarding in
MachineCopyPropagation (AArch64, AMDGPU, ARM, Hexagon, Mips, PowerPC,
RISCV, Sparc, SystemZ and X86).
Add some more comments describing the semantics of the
MachineOperand::isRenamable function and how it is set and maintained.
Change isRenamable to check the operand's opcode
hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq bit directly instead of
relying on it being consistently reflected in the IsRenamable bit
setting.
Clear the IsRenamable bit when changing an operand's register value.
Remove target code that was clearing the IsRenamable bit when changing
registers/opcodes now that this is done conservatively by default.
Change setting of hasExtraSrcRegAllocReq in AMDGPU target to be done in
one place covering all opcodes that have constant pipe read limit
restrictions.
Reviewers: qcolombet, MatzeB
Subscribers: aemerson, arsenm, jyknight, mcrosier, sdardis, nhaehnle, javed.absar, tpr, arichardson, kristof.beyls, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, sabuasal, niosHD, escha, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D43042
llvm-svn: 325931
2018-02-24 02:25:08 +08:00
|
|
|
let AllowRegisterRenaming = 1;
|
2012-12-12 05:25:42 +08:00
|
|
|
}
|
|
|
|
|
|
2014-06-14 00:38:59 +08:00
|
|
|
// Dummy Instruction itineraries for pseudo instructions
|
|
|
|
|
def ALU_NULL : FuncUnit;
|
|
|
|
|
def NullALU : InstrItinClass;
|
|
|
|
|
|
2014-05-17 04:56:45 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// Predicate helper class
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
2019-04-06 02:24:34 +08:00
|
|
|
def isGFX6 :
|
|
|
|
|
Predicate<"Subtarget->getGeneration() == AMDGPUSubtarget::SOUTHERN_ISLANDS">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureSouthernIslands)>;
|
2019-04-06 02:24:34 +08:00
|
|
|
|
|
|
|
|
def isGFX6GFX7 :
|
|
|
|
|
Predicate<"Subtarget->getGeneration() == AMDGPUSubtarget::SOUTHERN_ISLANDS ||"
|
|
|
|
|
"Subtarget->getGeneration() == AMDGPUSubtarget::SEA_ISLANDS">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of (not FeatureGCN3Encoding), (not FeatureGFX10Insts))>;
|
2019-04-25 01:03:15 +08:00
|
|
|
|
|
|
|
|
def isGFX6GFX7GFX10 :
|
|
|
|
|
Predicate<"Subtarget->getGeneration() == AMDGPUSubtarget::SOUTHERN_ISLANDS ||"
|
|
|
|
|
"Subtarget->getGeneration() == AMDGPUSubtarget::SEA_ISLANDS ||"
|
|
|
|
|
"Subtarget->getGeneration() == AMDGPUSubtarget::GFX10">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of (not FeatureGCN3Encoding))>;
|
2019-04-06 02:24:34 +08:00
|
|
|
|
2019-04-06 17:20:48 +08:00
|
|
|
def isGFX7Only :
|
2019-04-06 02:24:34 +08:00
|
|
|
Predicate<"Subtarget->getGeneration() == AMDGPUSubtarget::SEA_ISLANDS">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of (not FeatureGCN3Encoding), FeatureCIInsts, (not FeatureGFX10Insts))>;
|
2019-04-25 01:03:15 +08:00
|
|
|
|
|
|
|
|
def isGFX7GFX10 :
|
|
|
|
|
Predicate<"Subtarget->getGeneration() == AMDGPUSubtarget::SEA_ISLANDS ||"
|
|
|
|
|
"Subtarget->getGeneration() == AMDGPUSubtarget::GFX10">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of (not FeatureGCN3Encoding), FeatureCIInsts)>;
|
2019-04-06 02:24:34 +08:00
|
|
|
|
2020-08-21 17:42:49 +08:00
|
|
|
def isGFX7GFX8 :
|
|
|
|
|
Predicate<"Subtarget->getGeneration() == AMDGPUSubtarget::SEA_ISLANDS ||"
|
|
|
|
|
"Subtarget->getGeneration() == AMDGPUSubtarget::VOLCANIC_ISLANDS">,
|
|
|
|
|
AssemblerPredicate<(all_of FeatureSouthernIslands, FeatureCIInsts)>;
|
|
|
|
|
|
2019-04-06 02:24:34 +08:00
|
|
|
def isGFX7GFX8GFX9 :
|
|
|
|
|
Predicate<"Subtarget->getGeneration() == AMDGPUSubtarget::SEA_ISLANDS ||"
|
|
|
|
|
"Subtarget->getGeneration() == AMDGPUSubtarget::VOLCANIC_ISLANDS ||"
|
|
|
|
|
"Subtarget->getGeneration() == AMDGPUSubtarget::GFX9">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureGFX7GFX8GFX9Insts)>;
|
2019-04-06 02:24:34 +08:00
|
|
|
|
2019-04-25 01:03:15 +08:00
|
|
|
def isGFX6GFX7GFX8GFX9 :
|
|
|
|
|
Predicate<"Subtarget->getGeneration() == AMDGPUSubtarget::SOUTHERN_ISLANDS ||"
|
|
|
|
|
"Subtarget->getGeneration() == AMDGPUSubtarget::SEA_ISLANDS ||"
|
|
|
|
|
"Subtarget->getGeneration() == AMDGPUSubtarget::VOLCANIC_ISLANDS ||"
|
|
|
|
|
"Subtarget->getGeneration() == AMDGPUSubtarget::GFX9">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of (not FeatureGFX10Insts))>;
|
2019-04-25 01:03:15 +08:00
|
|
|
|
2019-04-06 02:24:34 +08:00
|
|
|
def isGFX7Plus :
|
|
|
|
|
Predicate<"Subtarget->getGeneration() >= AMDGPUSubtarget::SEA_ISLANDS">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureCIInsts)>;
|
2019-04-06 02:24:34 +08:00
|
|
|
|
|
|
|
|
def isGFX8Plus :
|
|
|
|
|
Predicate<"Subtarget->getGeneration() >= AMDGPUSubtarget::VOLCANIC_ISLANDS">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureGFX8Insts)>;
|
2019-04-06 02:24:34 +08:00
|
|
|
|
2019-04-06 17:20:48 +08:00
|
|
|
def isGFX8Only : Predicate<"Subtarget->getGeneration() =="
|
|
|
|
|
"AMDGPUSubtarget::VOLCANIC_ISLANDS">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate <(all_of FeatureVolcanicIslands)>;
|
2019-04-06 17:20:48 +08:00
|
|
|
|
2019-04-06 02:24:34 +08:00
|
|
|
def isGFX9Plus :
|
|
|
|
|
Predicate<"Subtarget->getGeneration() >= AMDGPUSubtarget::GFX9">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureGFX9Insts)>;
|
2015-04-24 03:33:54 +08:00
|
|
|
|
2019-04-06 17:20:48 +08:00
|
|
|
def isGFX9Only : Predicate <
|
2019-04-06 02:24:34 +08:00
|
|
|
"Subtarget->getGeneration() == AMDGPUSubtarget::GFX9">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureGCN3Encoding, FeatureGFX9Insts)>;
|
2016-01-26 12:49:22 +08:00
|
|
|
|
2019-04-06 17:20:48 +08:00
|
|
|
def isGFX8GFX9 :
|
|
|
|
|
Predicate<"Subtarget->getGeneration() == AMDGPUSubtarget::VOLCANIC_ISLANDS ||"
|
|
|
|
|
"Subtarget->getGeneration() == AMDGPUSubtarget::GFX9">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureGFX8Insts, FeatureGCN3Encoding)>;
|
2019-04-06 17:20:48 +08:00
|
|
|
|
2019-04-25 01:03:15 +08:00
|
|
|
def isGFX10Plus :
|
|
|
|
|
Predicate<"Subtarget->getGeneration() >= AMDGPUSubtarget::GFX10">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureGFX10Insts)>;
|
2019-04-25 01:03:15 +08:00
|
|
|
|
2017-06-21 03:54:14 +08:00
|
|
|
def HasFlatAddressSpace : Predicate<"Subtarget->hasFlatAddressSpace()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureFlatAddressSpace)>;
|
2017-06-21 03:54:14 +08:00
|
|
|
|
|
|
|
|
def HasFlatGlobalInsts : Predicate<"Subtarget->hasFlatGlobalInsts()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureFlatGlobalInsts)>;
|
2017-07-21 23:36:16 +08:00
|
|
|
def HasFlatScratchInsts : Predicate<"Subtarget->hasFlatScratchInsts()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureFlatScratchInsts)>;
|
2019-04-25 01:03:15 +08:00
|
|
|
def HasScalarFlatScratchInsts : Predicate<"Subtarget->hasScalarFlatScratchInsts()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureScalarFlatScratchInsts)>;
|
2017-09-02 02:36:06 +08:00
|
|
|
def HasD16LoadStore : Predicate<"Subtarget->hasD16LoadStore()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureGFX9Insts)>;
|
2016-01-26 12:49:22 +08:00
|
|
|
|
2020-10-16 05:57:34 +08:00
|
|
|
def HasFlatScratchSTMode : Predicate<"Subtarget->hasFlatScratchSTMode()">,
|
|
|
|
|
AssemblerPredicate<(any_of FeatureGFX10_3Insts)>;
|
|
|
|
|
|
2020-06-16 05:10:39 +08:00
|
|
|
def HasGFX10_BEncoding : Predicate<"Subtarget->hasGFX10_BEncoding()">,
|
|
|
|
|
AssemblerPredicate<(all_of FeatureGFX10_BEncoding)>;
|
|
|
|
|
|
2018-01-13 05:12:19 +08:00
|
|
|
def HasUnpackedD16VMem : Predicate<"Subtarget->hasUnpackedD16VMem()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureUnpackedD16VMem)>;
|
2018-01-13 05:12:19 +08:00
|
|
|
def HasPackedD16VMem : Predicate<"!Subtarget->hasUnpackedD16VMem()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of (not FeatureUnpackedD16VMem))>;
|
2018-01-13 05:12:19 +08:00
|
|
|
|
2018-11-06 06:44:19 +08:00
|
|
|
def D16PreservesUnusedBits :
|
2019-03-09 04:58:11 +08:00
|
|
|
Predicate<"Subtarget->d16PreservesUnusedBits()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureGFX9Insts, (not FeatureSRAMECC))>;
|
2017-11-29 08:55:57 +08:00
|
|
|
|
|
|
|
|
def LDSRequiresM0Init : Predicate<"Subtarget->ldsRequiresM0Init()">;
|
|
|
|
|
def NotLDSRequiresM0Init : Predicate<"!Subtarget->ldsRequiresM0Init()">;
|
|
|
|
|
|
2017-09-02 02:38:02 +08:00
|
|
|
def HasDSAddTid : Predicate<"Subtarget->getGeneration() >= AMDGPUSubtarget::GFX9">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureGFX9Insts)>;
|
2017-09-02 02:38:02 +08:00
|
|
|
|
2020-06-06 22:31:08 +08:00
|
|
|
def HasLDSFPAtomics : Predicate<"Subtarget->hasLDSFPAtomics()">,
|
|
|
|
|
AssemblerPredicate<(all_of FeatureGFX8Insts)>;
|
|
|
|
|
|
2018-09-21 18:31:22 +08:00
|
|
|
def HasAddNoCarryInsts : Predicate<"Subtarget->hasAddNoCarry()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureAddNoCarryInsts)>;
|
2017-07-21 01:42:47 +08:00
|
|
|
|
2019-02-22 02:19:54 +08:00
|
|
|
def NotHasAddNoCarryInsts : Predicate<"!Subtarget->hasAddNoCarry()">;
|
2017-07-21 01:42:47 +08:00
|
|
|
|
2017-02-28 02:49:11 +08:00
|
|
|
def Has16BitInsts : Predicate<"Subtarget->has16BitInsts()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of Feature16BitInsts)>;
|
2017-02-28 02:49:11 +08:00
|
|
|
def HasVOP3PInsts : Predicate<"Subtarget->hasVOP3PInsts()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureVOP3P)>;
|
2016-11-11 00:02:37 +08:00
|
|
|
|
2020-04-23 05:34:10 +08:00
|
|
|
def HasMinMaxDenormModes : Predicate<"Subtarget->supportsMinMaxDenormModes()">;
|
|
|
|
|
def NotHasMinMaxDenormModes : Predicate<"!Subtarget->supportsMinMaxDenormModes()">;
|
|
|
|
|
|
2017-01-20 18:01:25 +08:00
|
|
|
def HasSDWA : Predicate<"Subtarget->hasSDWA()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureSDWA, FeatureVolcanicIslands)>;
|
2017-05-23 18:08:55 +08:00
|
|
|
|
2019-04-06 02:24:34 +08:00
|
|
|
def HasSDWA9 :
|
|
|
|
|
Predicate<"Subtarget->hasSDWA()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureGCN3Encoding, FeatureGFX9Insts,FeatureSDWA)>;
|
2017-01-20 18:01:25 +08:00
|
|
|
|
2019-04-25 01:03:15 +08:00
|
|
|
def HasSDWA10 :
|
|
|
|
|
Predicate<"Subtarget->hasSDWA()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of (not FeatureGCN3Encoding), FeatureGFX10Insts, FeatureSDWA)>;
|
2019-04-25 01:03:15 +08:00
|
|
|
|
2017-01-20 18:01:25 +08:00
|
|
|
def HasDPP : Predicate<"Subtarget->hasDPP()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureGCN3Encoding, FeatureDPP)>;
|
2017-01-20 18:01:25 +08:00
|
|
|
|
2019-06-13 02:02:41 +08:00
|
|
|
def HasDPP8 : Predicate<"Subtarget->hasDPP8()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of (not FeatureGCN3Encoding), FeatureGFX10Insts, FeatureDPP8)>;
|
2019-06-13 02:02:41 +08:00
|
|
|
|
2018-08-28 23:07:30 +08:00
|
|
|
def HasR128A16 : Predicate<"Subtarget->hasR128A16()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureR128A16)>;
|
2018-08-28 23:07:30 +08:00
|
|
|
|
2020-01-29 17:04:36 +08:00
|
|
|
def HasGFX10A16 : Predicate<"Subtarget->hasGFX10A16()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureGFX10A16)>;
|
2020-01-29 17:04:36 +08:00
|
|
|
|
2020-03-25 15:38:22 +08:00
|
|
|
def HasG16 : Predicate<"Subtarget->hasG16()">,
|
|
|
|
|
AssemblerPredicate<(all_of FeatureG16)>;
|
|
|
|
|
|
2019-06-13 02:02:41 +08:00
|
|
|
def HasDPP16 : Predicate<"Subtarget->hasDPP()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of (not FeatureGCN3Encoding), FeatureGFX10Insts, FeatureDPP)>;
|
2019-06-13 02:02:41 +08:00
|
|
|
|
2017-08-16 21:51:56 +08:00
|
|
|
def HasIntClamp : Predicate<"Subtarget->hasIntClamp()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureIntClamp)>;
|
2017-08-16 21:51:56 +08:00
|
|
|
|
2017-10-25 15:00:51 +08:00
|
|
|
def HasMadMixInsts : Predicate<"Subtarget->hasMadMixInsts()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureMadMixInsts)>;
|
2017-09-08 02:05:07 +08:00
|
|
|
|
2019-04-25 01:03:15 +08:00
|
|
|
def HasScalarStores : Predicate<"Subtarget->hasScalarStores()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureScalarStores)>;
|
2019-04-25 01:03:15 +08:00
|
|
|
|
2018-04-03 00:10:25 +08:00
|
|
|
def HasScalarAtomics : Predicate<"Subtarget->hasScalarAtomics()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureScalarAtomics)>;
|
2018-04-03 00:10:25 +08:00
|
|
|
|
2019-04-25 01:03:15 +08:00
|
|
|
def HasNoSdstCMPX : Predicate<"Subtarget->hasNoSdstCMPX()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureNoSdstCMPX)>;
|
2019-04-25 01:03:15 +08:00
|
|
|
|
|
|
|
|
def HasSdstCMPX : Predicate<"!Subtarget->hasNoSdstCMPX()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of (not FeatureNoSdstCMPX))>;
|
2019-04-25 01:03:15 +08:00
|
|
|
|
2018-04-27 03:21:26 +08:00
|
|
|
def has16BankLDS : Predicate<"Subtarget->getLDSBankCount() == 16">;
|
|
|
|
|
def has32BankLDS : Predicate<"Subtarget->getLDSBankCount() == 32">;
|
|
|
|
|
def HasVGPRIndexMode : Predicate<"Subtarget->hasVGPRIndexMode()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureVGPRIndexMode)>;
|
2018-04-27 03:21:26 +08:00
|
|
|
def HasMovrel : Predicate<"Subtarget->hasMovrel()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureMovrel)>;
|
2018-04-27 03:21:26 +08:00
|
|
|
|
2018-05-01 03:08:16 +08:00
|
|
|
def HasFmaMixInsts : Predicate<"Subtarget->hasFmaMixInsts()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureFmaMixInsts)>;
|
2018-05-01 03:08:16 +08:00
|
|
|
|
|
|
|
|
def HasDLInsts : Predicate<"Subtarget->hasDLInsts()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureDLInsts)>;
|
2018-05-01 03:08:16 +08:00
|
|
|
|
2019-02-09 08:34:21 +08:00
|
|
|
def HasDot1Insts : Predicate<"Subtarget->hasDot1Insts()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureDot1Insts)>;
|
2019-02-09 08:34:21 +08:00
|
|
|
|
|
|
|
|
def HasDot2Insts : Predicate<"Subtarget->hasDot2Insts()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureDot2Insts)>;
|
2019-01-10 11:25:20 +08:00
|
|
|
|
2019-07-10 02:10:06 +08:00
|
|
|
def HasDot3Insts : Predicate<"Subtarget->hasDot3Insts()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureDot3Insts)>;
|
2019-07-10 02:10:06 +08:00
|
|
|
|
|
|
|
|
def HasDot4Insts : Predicate<"Subtarget->hasDot4Insts()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureDot4Insts)>;
|
2019-07-10 02:10:06 +08:00
|
|
|
|
2019-06-14 08:33:31 +08:00
|
|
|
def HasDot5Insts : Predicate<"Subtarget->hasDot5Insts()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureDot5Insts)>;
|
2019-06-14 08:33:31 +08:00
|
|
|
|
|
|
|
|
def HasDot6Insts : Predicate<"Subtarget->hasDot6Insts()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureDot6Insts)>;
|
2018-05-01 03:08:16 +08:00
|
|
|
|
2020-06-16 05:10:39 +08:00
|
|
|
def HasGetWaveIdInst : Predicate<"Subtarget->hasGetWaveIdInst()">,
|
|
|
|
|
AssemblerPredicate<(all_of FeatureGetWaveIdInst)>;
|
|
|
|
|
|
2019-07-10 02:10:06 +08:00
|
|
|
def HasMAIInsts : Predicate<"Subtarget->hasMAIInsts()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureMAIInsts)>;
|
2019-07-10 02:10:06 +08:00
|
|
|
|
2020-06-16 05:10:39 +08:00
|
|
|
def HasSMemTimeInst : Predicate<"Subtarget->hasSMemTimeInst()">,
|
|
|
|
|
AssemblerPredicate<(all_of FeatureSMemTimeInst)>;
|
|
|
|
|
|
|
|
|
|
def HasNoSMemTimeInst : Predicate<"!Subtarget->hasSMemTimeInst()">;
|
|
|
|
|
|
2019-07-10 02:10:06 +08:00
|
|
|
def HasPkFmacF16Inst : Predicate<"Subtarget->hasPkFmacF16Inst()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeaturePkFmacF16Inst)>;
|
2019-07-10 02:10:06 +08:00
|
|
|
|
2020-06-16 05:10:39 +08:00
|
|
|
def HasMadMacF32Insts : Predicate<"Subtarget->hasMadMacF32Insts()">,
|
|
|
|
|
AssemblerPredicate<(all_of FeatureMadMacF32Insts)>;
|
|
|
|
|
|
2020-10-28 01:00:53 +08:00
|
|
|
def HasFmaLegacy32 : Predicate<"Subtarget->hasGFX10_3Insts()">,
|
|
|
|
|
AssemblerPredicate<(any_of FeatureGFX10_3Insts)>;
|
|
|
|
|
|
2019-07-10 02:10:06 +08:00
|
|
|
def HasAtomicFaddInsts : Predicate<"Subtarget->hasAtomicFaddInsts()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureAtomicFaddInsts)>;
|
2019-07-10 02:10:06 +08:00
|
|
|
|
2020-06-16 05:10:39 +08:00
|
|
|
def HasDsSrc2Insts : Predicate<"!Subtarget->hasDsSrc2Insts()">,
|
|
|
|
|
AssemblerPredicate<(all_of FeatureDsSrc2Insts)>;
|
|
|
|
|
|
2019-06-27 01:34:57 +08:00
|
|
|
def HasOffset3fBug : Predicate<"!Subtarget->hasOffset3fBug()">,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
AssemblerPredicate<(all_of FeatureOffset3fBug)>;
|
2019-06-27 01:34:57 +08:00
|
|
|
|
2017-10-11 04:22:07 +08:00
|
|
|
def EnableLateCFGStructurize : Predicate<
|
|
|
|
|
"EnableLateStructurizeCFG">;
|
2017-10-03 08:06:41 +08:00
|
|
|
|
2020-10-22 05:27:03 +08:00
|
|
|
def EnableFlatScratch : Predicate<"Subtarget->enableFlatScratch()">;
|
|
|
|
|
|
|
|
|
|
def DisableFlatScratch : Predicate<"!Subtarget->enableFlatScratch()">;
|
|
|
|
|
|
2012-12-12 05:25:42 +08:00
|
|
|
// Include AMDGPU TD files
|
|
|
|
|
include "SISchedule.td"
|
2017-11-11 04:01:58 +08:00
|
|
|
include "GCNProcessors.td"
|
2012-12-12 05:25:42 +08:00
|
|
|
include "AMDGPUInstrInfo.td"
|
2020-02-12 02:55:14 +08:00
|
|
|
include "SIRegisterInfo.td"
|
Re-commit AMDGPU/GlobalISel: Add support for simple shaders
Fix build when global-isel is disabled and fix a warning.
Summary: We can select constant/global G_LOAD, global G_STORE, and G_GEP.
Reviewers: qcolombet, MatzeB, t.p.northover, ab, arsenm
Subscribers: mehdi_amini, vkalintiris, kzhuravl, wdng, nhaehnle, mgorny, yaxunl, tony-tye, modocache, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D26730
llvm-svn: 293551
2017-01-31 05:56:46 +08:00
|
|
|
include "AMDGPURegisterBanks.td"
|
2012-12-12 05:25:42 +08:00
|
|
|
include "AMDGPUInstructions.td"
|
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
|
|
|
include "SIInstrInfo.td"
|
2013-03-07 17:03:52 +08:00
|
|
|
include "AMDGPUCallingConv.td"
|
AMDGPU: Make getTgtMemIntrinsic table-driven for resource-based intrinsics
Summary:
Avoids having to list all intrinsics manually.
This is in preparation for the new dimension-aware image intrinsics,
which I'd rather not have to list here by hand.
Change-Id: If7ced04998397ef68c4cb8f7de66b5050fb767e5
Reviewers: arsenm, rampitec, b-sumner
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, tpr, llvm-commits, t-tye
Differential Revision: https://reviews.llvm.org/D44937
llvm-svn: 328938
2018-04-02 01:09:07 +08:00
|
|
|
include "AMDGPUSearchableTables.td"
|