2013-02-26 18:52:03 +01:00
|
|
|
//===-- SIRegisterInfo.td - SI Register defs ---------------*- tablegen -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Declarations that describe the SI registers
|
|
|
|
//===----------------------------------------------------------------------===//
|
2015-07-31 03:12:10 +02:00
|
|
|
class SIReg <string n, bits<16> regIdx = 0> : Register<n>,
|
|
|
|
DwarfRegNum<[!cast<int>(HWEncoding)]> {
|
2012-12-11 22:25:42 +01:00
|
|
|
let Namespace = "AMDGPU";
|
2015-07-31 03:12:10 +02:00
|
|
|
|
|
|
|
// This is the not yet the complete register encoding. An additional
|
|
|
|
// bit is set for VGPRs.
|
|
|
|
let HWEncoding = regIdx;
|
2012-12-11 22:25:42 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
// Special Registers
|
2014-03-17 18:03:51 +01:00
|
|
|
def VCC_LO : SIReg<"vcc_lo", 106>;
|
|
|
|
def VCC_HI : SIReg<"vcc_hi", 107>;
|
|
|
|
|
|
|
|
// VCC for 64-bit instructions
|
2015-07-31 03:12:10 +02:00
|
|
|
def VCC : RegisterWithSubRegs<"vcc", [VCC_LO, VCC_HI]>,
|
|
|
|
DwarfRegAlias<VCC_LO> {
|
2014-03-17 18:03:51 +01:00
|
|
|
let Namespace = "AMDGPU";
|
|
|
|
let SubRegIndices = [sub0, sub1];
|
|
|
|
let HWEncoding = 106;
|
|
|
|
}
|
|
|
|
|
2014-11-14 15:08:04 +01:00
|
|
|
def EXEC_LO : SIReg<"exec_lo", 126>;
|
|
|
|
def EXEC_HI : SIReg<"exec_hi", 127>;
|
2014-08-05 19:52:37 +02:00
|
|
|
|
2015-07-31 03:12:10 +02:00
|
|
|
def EXEC : RegisterWithSubRegs<"EXEC", [EXEC_LO, EXEC_HI]>,
|
|
|
|
DwarfRegAlias<EXEC_LO> {
|
2014-08-05 19:52:37 +02:00
|
|
|
let Namespace = "AMDGPU";
|
|
|
|
let SubRegIndices = [sub0, sub1];
|
|
|
|
let HWEncoding = 126;
|
|
|
|
}
|
|
|
|
|
2015-02-13 22:02:36 +01:00
|
|
|
def SCC : SIReg<"scc", 253>;
|
|
|
|
def M0 : SIReg <"m0", 124>;
|
2012-12-11 22:25:42 +01:00
|
|
|
|
2017-02-18 19:29:53 +01:00
|
|
|
def SRC_SHARED_BASE : SIReg<"src_shared_base", 235>;
|
|
|
|
def SRC_SHARED_LIMIT : SIReg<"src_shared_limit", 236>;
|
|
|
|
def SRC_PRIVATE_BASE : SIReg<"src_private_base", 237>;
|
|
|
|
def SRC_PRIVATE_LIMIT : SIReg<"src_private_limit", 238>;
|
|
|
|
|
2016-04-13 18:18:41 +02:00
|
|
|
// Trap handler registers
|
|
|
|
def TBA_LO : SIReg<"tba_lo", 108>;
|
|
|
|
def TBA_HI : SIReg<"tba_hi", 109>;
|
|
|
|
|
|
|
|
def TBA : RegisterWithSubRegs<"tba", [TBA_LO, TBA_HI]>,
|
|
|
|
DwarfRegAlias<TBA_LO> {
|
|
|
|
let Namespace = "AMDGPU";
|
|
|
|
let SubRegIndices = [sub0, sub1];
|
|
|
|
let HWEncoding = 108;
|
|
|
|
}
|
|
|
|
|
|
|
|
def TMA_LO : SIReg<"tma_lo", 110>;
|
|
|
|
def TMA_HI : SIReg<"tma_hi", 111>;
|
|
|
|
|
|
|
|
def TMA : RegisterWithSubRegs<"tma", [TMA_LO, TMA_HI]>,
|
|
|
|
DwarfRegAlias<TMA_LO> {
|
|
|
|
let Namespace = "AMDGPU";
|
|
|
|
let SubRegIndices = [sub0, sub1];
|
|
|
|
let HWEncoding = 110;
|
|
|
|
}
|
|
|
|
|
|
|
|
def TTMP0 : SIReg <"ttmp0", 112>;
|
|
|
|
def TTMP1 : SIReg <"ttmp1", 113>;
|
|
|
|
def TTMP2 : SIReg <"ttmp2", 114>;
|
|
|
|
def TTMP3 : SIReg <"ttmp3", 115>;
|
|
|
|
def TTMP4 : SIReg <"ttmp4", 116>;
|
|
|
|
def TTMP5 : SIReg <"ttmp5", 117>;
|
|
|
|
def TTMP6 : SIReg <"ttmp6", 118>;
|
|
|
|
def TTMP7 : SIReg <"ttmp7", 119>;
|
|
|
|
def TTMP8 : SIReg <"ttmp8", 120>;
|
|
|
|
def TTMP9 : SIReg <"ttmp9", 121>;
|
|
|
|
def TTMP10 : SIReg <"ttmp10", 122>;
|
|
|
|
def TTMP11 : SIReg <"ttmp11", 123>;
|
|
|
|
|
2015-12-21 19:44:27 +01:00
|
|
|
multiclass FLAT_SCR_LOHI_m <string n, bits<16> ci_e, bits<16> vi_e> {
|
|
|
|
def _ci : SIReg<n, ci_e>;
|
|
|
|
def _vi : SIReg<n, vi_e>;
|
|
|
|
def "" : SIReg<"", 0>;
|
|
|
|
}
|
2014-09-15 17:41:53 +02:00
|
|
|
|
2015-12-21 19:44:27 +01:00
|
|
|
class FlatReg <Register lo, Register hi, bits<16> encoding> :
|
|
|
|
RegisterWithSubRegs<"flat_scratch", [lo, hi]>,
|
|
|
|
DwarfRegAlias<lo> {
|
2014-09-15 17:41:53 +02:00
|
|
|
let Namespace = "AMDGPU";
|
|
|
|
let SubRegIndices = [sub0, sub1];
|
2015-12-21 19:44:27 +01:00
|
|
|
let HWEncoding = encoding;
|
2014-09-15 17:41:53 +02:00
|
|
|
}
|
|
|
|
|
2015-12-21 19:44:27 +01:00
|
|
|
defm FLAT_SCR_LO : FLAT_SCR_LOHI_m<"flat_scratch_lo", 104, 102>; // Offset in units of 256-bytes.
|
|
|
|
defm FLAT_SCR_HI : FLAT_SCR_LOHI_m<"flat_scratch_hi", 105, 103>; // Size is the per-thread scratch size, in bytes.
|
|
|
|
|
|
|
|
def FLAT_SCR_ci : FlatReg<FLAT_SCR_LO_ci, FLAT_SCR_HI_ci, 104>;
|
|
|
|
def FLAT_SCR_vi : FlatReg<FLAT_SCR_LO_vi, FLAT_SCR_HI_vi, 102>;
|
|
|
|
def FLAT_SCR : FlatReg<FLAT_SCR_LO, FLAT_SCR_HI, 0>;
|
|
|
|
|
2013-02-26 18:52:03 +01:00
|
|
|
// SGPR registers
|
2015-11-03 23:39:50 +01:00
|
|
|
foreach Index = 0-103 in {
|
2013-02-26 18:52:03 +01:00
|
|
|
def SGPR#Index : SIReg <"SGPR"#Index, Index>;
|
|
|
|
}
|
|
|
|
|
|
|
|
// VGPR registers
|
|
|
|
foreach Index = 0-255 in {
|
|
|
|
def VGPR#Index : SIReg <"VGPR"#Index, Index> {
|
|
|
|
let HWEncoding{8} = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Groupings using register classes and tuples
|
|
|
|
//===----------------------------------------------------------------------===//
|
2012-12-11 22:25:42 +01:00
|
|
|
|
2016-02-13 00:45:29 +01:00
|
|
|
def SCC_CLASS : RegisterClass<"AMDGPU", [i1], 1, (add SCC)> {
|
|
|
|
let CopyCost = -1;
|
|
|
|
let isAllocatable = 0;
|
|
|
|
}
|
|
|
|
|
2016-11-25 18:37:09 +01:00
|
|
|
def M0_CLASS : RegisterClass<"AMDGPU", [i32], 32, (add M0)> {
|
|
|
|
let CopyCost = 1;
|
|
|
|
let isAllocatable = 0;
|
|
|
|
}
|
|
|
|
|
2015-07-31 03:12:10 +02:00
|
|
|
// TODO: Do we need to set DwarfRegAlias on register tuples?
|
|
|
|
|
2013-02-26 18:52:03 +01:00
|
|
|
// SGPR 32-bit registers
|
2017-02-27 19:49:11 +01:00
|
|
|
def SGPR_32 : RegisterClass<"AMDGPU", [i32, f32, i16, f16, v2i16, v2f16], 32,
|
2016-05-21 05:55:07 +02:00
|
|
|
(add (sequence "SGPR%u", 0, 103))> {
|
2016-12-14 17:52:06 +01:00
|
|
|
// Give all SGPR classes higher priority than VGPR classes, because
|
|
|
|
// we want to spill SGPRs to VGPRs.
|
|
|
|
let AllocationPriority = 7;
|
2016-05-21 05:55:07 +02:00
|
|
|
}
|
2012-12-11 22:25:42 +01:00
|
|
|
|
|
|
|
// SGPR 64-bit registers
|
2013-10-10 19:11:55 +02:00
|
|
|
def SGPR_64Regs : RegisterTuples<[sub0, sub1],
|
2015-11-03 23:39:50 +01:00
|
|
|
[(add (decimate SGPR_32, 2)),
|
2013-02-26 18:52:03 +01:00
|
|
|
(add (decimate (shl SGPR_32, 1), 2))]>;
|
2012-12-11 22:25:42 +01:00
|
|
|
|
|
|
|
// SGPR 128-bit registers
|
2016-04-29 19:04:50 +02:00
|
|
|
def SGPR_128Regs : RegisterTuples<[sub0, sub1, sub2, sub3],
|
2015-11-03 23:39:50 +01:00
|
|
|
[(add (decimate SGPR_32, 4)),
|
2013-02-26 18:52:03 +01:00
|
|
|
(add (decimate (shl SGPR_32, 1), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 2), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 3), 4))]>;
|
2012-12-11 22:25:42 +01:00
|
|
|
|
|
|
|
// SGPR 256-bit registers
|
|
|
|
def SGPR_256 : RegisterTuples<[sub0, sub1, sub2, sub3, sub4, sub5, sub6, sub7],
|
2015-11-03 23:39:50 +01:00
|
|
|
[(add (decimate SGPR_32, 4)),
|
2013-02-26 18:52:03 +01:00
|
|
|
(add (decimate (shl SGPR_32, 1), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 2), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 3), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 4), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 5), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 6), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 7), 4))]>;
|
|
|
|
|
|
|
|
// SGPR 512-bit registers
|
|
|
|
def SGPR_512 : RegisterTuples<[sub0, sub1, sub2, sub3, sub4, sub5, sub6, sub7,
|
|
|
|
sub8, sub9, sub10, sub11, sub12, sub13, sub14, sub15],
|
2015-11-03 23:39:50 +01:00
|
|
|
[(add (decimate SGPR_32, 4)),
|
2013-02-26 18:52:03 +01:00
|
|
|
(add (decimate (shl SGPR_32, 1), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 2), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 3), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 4), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 5), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 6), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 7), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 8), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 9), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 10), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 11), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 12), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 13), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 14), 4)),
|
|
|
|
(add (decimate (shl SGPR_32, 15), 4))]>;
|
2012-12-11 22:25:42 +01:00
|
|
|
|
2016-04-13 18:18:41 +02:00
|
|
|
// Trap handler TMP 32-bit registers
|
2017-02-27 19:49:11 +01:00
|
|
|
def TTMP_32 : RegisterClass<"AMDGPU", [i32, f32, v2i16, v2f16], 32,
|
2016-04-13 18:18:41 +02:00
|
|
|
(add (sequence "TTMP%u", 0, 11))> {
|
|
|
|
let isAllocatable = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Trap handler TMP 64-bit registers
|
|
|
|
def TTMP_64Regs : RegisterTuples<[sub0, sub1],
|
|
|
|
[(add (decimate TTMP_32, 2)),
|
|
|
|
(add (decimate (shl TTMP_32, 1), 2))]>;
|
|
|
|
|
|
|
|
// Trap handler TMP 128-bit registers
|
|
|
|
def TTMP_128Regs : RegisterTuples<[sub0, sub1, sub2, sub3],
|
|
|
|
[(add (decimate TTMP_32, 4)),
|
|
|
|
(add (decimate (shl TTMP_32, 1), 4)),
|
|
|
|
(add (decimate (shl TTMP_32, 2), 4)),
|
|
|
|
(add (decimate (shl TTMP_32, 3), 4))]>;
|
|
|
|
|
2012-12-11 22:25:42 +01:00
|
|
|
// VGPR 32-bit registers
|
2017-02-27 19:49:11 +01:00
|
|
|
// i16/f16 only on VI+
|
|
|
|
def VGPR_32 : RegisterClass<"AMDGPU", [i32, f32, i16, f16, v2i16, v2f16], 32,
|
2016-05-21 05:55:07 +02:00
|
|
|
(add (sequence "VGPR%u", 0, 255))> {
|
|
|
|
let AllocationPriority = 1;
|
2016-09-03 19:25:44 +02:00
|
|
|
let Size = 32;
|
2016-05-21 05:55:07 +02:00
|
|
|
}
|
2012-12-11 22:25:42 +01:00
|
|
|
|
|
|
|
// VGPR 64-bit registers
|
2013-02-07 15:02:37 +01:00
|
|
|
def VGPR_64 : RegisterTuples<[sub0, sub1],
|
2013-02-26 18:52:03 +01:00
|
|
|
[(add (trunc VGPR_32, 255)),
|
|
|
|
(add (shl VGPR_32, 1))]>;
|
2012-12-11 22:25:42 +01:00
|
|
|
|
2013-04-10 10:39:16 +02:00
|
|
|
// VGPR 96-bit registers
|
|
|
|
def VGPR_96 : RegisterTuples<[sub0, sub1, sub2],
|
|
|
|
[(add (trunc VGPR_32, 254)),
|
|
|
|
(add (shl VGPR_32, 1)),
|
|
|
|
(add (shl VGPR_32, 2))]>;
|
|
|
|
|
2012-12-11 22:25:42 +01:00
|
|
|
// VGPR 128-bit registers
|
2013-02-07 15:02:37 +01:00
|
|
|
def VGPR_128 : RegisterTuples<[sub0, sub1, sub2, sub3],
|
2013-02-26 18:52:03 +01:00
|
|
|
[(add (trunc VGPR_32, 253)),
|
|
|
|
(add (shl VGPR_32, 1)),
|
|
|
|
(add (shl VGPR_32, 2)),
|
|
|
|
(add (shl VGPR_32, 3))]>;
|
2012-12-11 22:25:42 +01:00
|
|
|
|
2013-02-07 18:02:09 +01:00
|
|
|
// VGPR 256-bit registers
|
|
|
|
def VGPR_256 : RegisterTuples<[sub0, sub1, sub2, sub3, sub4, sub5, sub6, sub7],
|
2013-02-26 18:52:03 +01:00
|
|
|
[(add (trunc VGPR_32, 249)),
|
|
|
|
(add (shl VGPR_32, 1)),
|
|
|
|
(add (shl VGPR_32, 2)),
|
|
|
|
(add (shl VGPR_32, 3)),
|
|
|
|
(add (shl VGPR_32, 4)),
|
|
|
|
(add (shl VGPR_32, 5)),
|
|
|
|
(add (shl VGPR_32, 6)),
|
|
|
|
(add (shl VGPR_32, 7))]>;
|
2013-02-07 18:02:09 +01:00
|
|
|
|
|
|
|
// VGPR 512-bit registers
|
|
|
|
def VGPR_512 : RegisterTuples<[sub0, sub1, sub2, sub3, sub4, sub5, sub6, sub7,
|
|
|
|
sub8, sub9, sub10, sub11, sub12, sub13, sub14, sub15],
|
2013-02-26 18:52:03 +01:00
|
|
|
[(add (trunc VGPR_32, 241)),
|
|
|
|
(add (shl VGPR_32, 1)),
|
|
|
|
(add (shl VGPR_32, 2)),
|
|
|
|
(add (shl VGPR_32, 3)),
|
|
|
|
(add (shl VGPR_32, 4)),
|
|
|
|
(add (shl VGPR_32, 5)),
|
|
|
|
(add (shl VGPR_32, 6)),
|
|
|
|
(add (shl VGPR_32, 7)),
|
|
|
|
(add (shl VGPR_32, 8)),
|
|
|
|
(add (shl VGPR_32, 9)),
|
|
|
|
(add (shl VGPR_32, 10)),
|
|
|
|
(add (shl VGPR_32, 11)),
|
|
|
|
(add (shl VGPR_32, 12)),
|
|
|
|
(add (shl VGPR_32, 13)),
|
|
|
|
(add (shl VGPR_32, 14)),
|
|
|
|
(add (shl VGPR_32, 15))]>;
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Register classes used as source and destination
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2016-04-29 19:04:50 +02:00
|
|
|
// Subset of SReg_32 without M0 for SMRD instructions and alike.
|
|
|
|
// See comments in SIInstructions.td for more info.
|
2017-02-27 19:49:11 +01:00
|
|
|
def SReg_32_XM0_XEXEC : RegisterClass<"AMDGPU", [i32, f32, i16, f16, v2i16, v2f16], 32,
|
2016-11-29 20:39:53 +01:00
|
|
|
(add SGPR_32, VCC_LO, VCC_HI, FLAT_SCR_LO, FLAT_SCR_HI,
|
2017-02-18 19:29:53 +01:00
|
|
|
TTMP_32, TMA_LO, TMA_HI, TBA_LO, TBA_HI, SRC_SHARED_BASE, SRC_SHARED_LIMIT,
|
|
|
|
SRC_PRIVATE_BASE, SRC_PRIVATE_LIMIT)> {
|
2016-12-14 17:52:06 +01:00
|
|
|
let AllocationPriority = 7;
|
2016-05-21 05:55:07 +02:00
|
|
|
}
|
2016-04-29 19:04:50 +02:00
|
|
|
|
2017-03-21 17:42:50 +01:00
|
|
|
def SReg_32_XM0 : RegisterClass<"AMDGPU", [i32, f32, i16, f16, v2i16, v2f16], 32,
|
2016-11-29 20:39:53 +01:00
|
|
|
(add SReg_32_XM0_XEXEC, EXEC_LO, EXEC_HI)> {
|
2016-12-14 17:52:06 +01:00
|
|
|
let AllocationPriority = 7;
|
2016-11-29 20:39:53 +01:00
|
|
|
}
|
|
|
|
|
2016-05-21 02:53:28 +02:00
|
|
|
// Register class for all scalar registers (SGPRs + Special Registers)
|
2017-02-27 19:49:11 +01:00
|
|
|
def SReg_32 : RegisterClass<"AMDGPU", [i32, f32, i16, f16, v2i16, v2f16], 32,
|
2016-11-29 20:39:53 +01:00
|
|
|
(add SReg_32_XM0, M0_CLASS, EXEC_LO, EXEC_HI)> {
|
2016-12-14 17:52:06 +01:00
|
|
|
let AllocationPriority = 7;
|
2016-05-21 05:55:07 +02:00
|
|
|
}
|
2016-05-21 02:53:28 +02:00
|
|
|
|
2016-05-21 05:55:07 +02:00
|
|
|
def SGPR_64 : RegisterClass<"AMDGPU", [v2i32, i64, f64], 32, (add SGPR_64Regs)> {
|
2016-11-29 20:39:53 +01:00
|
|
|
let CopyCost = 1;
|
2016-12-14 17:52:06 +01:00
|
|
|
let AllocationPriority = 8;
|
2016-05-21 05:55:07 +02:00
|
|
|
}
|
2013-10-10 19:11:55 +02:00
|
|
|
|
2016-04-13 18:18:41 +02:00
|
|
|
def TTMP_64 : RegisterClass<"AMDGPU", [v2i32, i64, f64], 32, (add TTMP_64Regs)> {
|
|
|
|
let isAllocatable = 0;
|
|
|
|
}
|
|
|
|
|
2016-11-29 20:39:53 +01:00
|
|
|
def SReg_64_XEXEC : RegisterClass<"AMDGPU", [v2i32, i64, f64, i1], 32,
|
2016-12-09 18:49:11 +01:00
|
|
|
(add SGPR_64, VCC, FLAT_SCR, TTMP_64, TBA, TMA)> {
|
2016-11-29 20:39:53 +01:00
|
|
|
let CopyCost = 1;
|
2016-12-14 17:52:06 +01:00
|
|
|
let AllocationPriority = 8;
|
2016-11-29 20:39:53 +01:00
|
|
|
}
|
|
|
|
|
2015-11-06 18:54:47 +01:00
|
|
|
def SReg_64 : RegisterClass<"AMDGPU", [v2i32, i64, f64, i1], 32,
|
2016-12-09 18:49:11 +01:00
|
|
|
(add SReg_64_XEXEC, EXEC)> {
|
2016-11-29 20:39:53 +01:00
|
|
|
let CopyCost = 1;
|
2016-12-14 17:52:06 +01:00
|
|
|
let AllocationPriority = 8;
|
2016-05-21 05:55:07 +02:00
|
|
|
}
|
2012-12-11 22:25:42 +01:00
|
|
|
|
2016-04-29 19:04:50 +02:00
|
|
|
// Requires 2 s_mov_b64 to copy
|
|
|
|
let CopyCost = 2 in {
|
|
|
|
|
2016-05-21 05:55:07 +02:00
|
|
|
def SGPR_128 : RegisterClass<"AMDGPU", [v4i32, v16i8, v2i64], 32, (add SGPR_128Regs)> {
|
2016-12-14 17:52:06 +01:00
|
|
|
let AllocationPriority = 10;
|
2016-05-21 05:55:07 +02:00
|
|
|
}
|
2016-04-29 19:04:50 +02:00
|
|
|
|
|
|
|
def TTMP_128 : RegisterClass<"AMDGPU", [v4i32, v16i8, v2i64], 32, (add TTMP_128Regs)> {
|
|
|
|
let isAllocatable = 0;
|
2015-09-26 06:09:34 +02:00
|
|
|
}
|
2012-12-11 22:25:42 +01:00
|
|
|
|
2016-05-21 05:55:07 +02:00
|
|
|
def SReg_128 : RegisterClass<"AMDGPU", [v4i32, v16i8, v2i64], 32, (add SGPR_128, TTMP_128)> {
|
2016-12-14 17:52:06 +01:00
|
|
|
let AllocationPriority = 10;
|
2016-05-21 05:55:07 +02:00
|
|
|
}
|
2016-04-29 19:04:50 +02:00
|
|
|
|
|
|
|
} // End CopyCost = 2
|
|
|
|
|
2016-01-26 05:43:48 +01:00
|
|
|
def SReg_256 : RegisterClass<"AMDGPU", [v8i32, v8f32], 32, (add SGPR_256)> {
|
2015-09-26 06:09:34 +02:00
|
|
|
// Requires 4 s_mov_b64 to copy
|
|
|
|
let CopyCost = 4;
|
2016-12-14 17:52:06 +01:00
|
|
|
let AllocationPriority = 11;
|
2015-09-26 06:09:34 +02:00
|
|
|
}
|
2012-12-11 22:25:42 +01:00
|
|
|
|
2017-02-21 20:12:08 +01:00
|
|
|
def SReg_512 : RegisterClass<"AMDGPU", [v16i32, v16f32], 32, (add SGPR_512)> {
|
2015-09-26 06:09:34 +02:00
|
|
|
// Requires 8 s_mov_b64 to copy
|
|
|
|
let CopyCost = 8;
|
2016-12-14 17:52:06 +01:00
|
|
|
let AllocationPriority = 12;
|
2015-09-26 06:09:34 +02:00
|
|
|
}
|
2013-02-26 18:52:03 +01:00
|
|
|
|
2012-12-11 22:25:42 +01:00
|
|
|
// Register class for all vector registers (VGPRs + Interploation Registers)
|
2015-11-06 18:54:47 +01:00
|
|
|
def VReg_64 : RegisterClass<"AMDGPU", [i64, f64, v2i32, v2f32], 32, (add VGPR_64)> {
|
2016-09-03 19:25:44 +02:00
|
|
|
let Size = 64;
|
|
|
|
|
2015-09-26 06:09:34 +02:00
|
|
|
// Requires 2 v_mov_b32 to copy
|
|
|
|
let CopyCost = 2;
|
2016-05-21 05:55:07 +02:00
|
|
|
let AllocationPriority = 2;
|
2015-09-26 06:09:34 +02:00
|
|
|
}
|
2013-02-26 18:52:03 +01:00
|
|
|
|
2015-11-06 18:54:47 +01:00
|
|
|
def VReg_96 : RegisterClass<"AMDGPU", [untyped], 32, (add VGPR_96)> {
|
2013-04-10 10:39:16 +02:00
|
|
|
let Size = 96;
|
2015-09-26 06:09:34 +02:00
|
|
|
|
|
|
|
// Requires 3 v_mov_b32 to copy
|
|
|
|
let CopyCost = 3;
|
2016-05-21 05:55:07 +02:00
|
|
|
let AllocationPriority = 3;
|
2013-04-10 10:39:16 +02:00
|
|
|
}
|
|
|
|
|
2015-11-25 20:58:34 +01:00
|
|
|
def VReg_128 : RegisterClass<"AMDGPU", [v4i32, v4f32, v2i64, v2f64], 32, (add VGPR_128)> {
|
2016-09-03 19:25:44 +02:00
|
|
|
let Size = 128;
|
|
|
|
|
2015-09-26 06:09:34 +02:00
|
|
|
// Requires 4 v_mov_b32 to copy
|
|
|
|
let CopyCost = 4;
|
2016-05-21 05:55:07 +02:00
|
|
|
let AllocationPriority = 4;
|
2015-09-26 06:09:34 +02:00
|
|
|
}
|
2013-02-26 18:52:03 +01:00
|
|
|
|
2016-01-26 05:43:48 +01:00
|
|
|
def VReg_256 : RegisterClass<"AMDGPU", [v8i32, v8f32], 32, (add VGPR_256)> {
|
2016-09-03 19:25:44 +02:00
|
|
|
let Size = 256;
|
2015-09-26 06:09:34 +02:00
|
|
|
let CopyCost = 8;
|
2016-05-21 05:55:07 +02:00
|
|
|
let AllocationPriority = 5;
|
2015-09-26 06:09:34 +02:00
|
|
|
}
|
2013-02-26 18:52:03 +01:00
|
|
|
|
2015-11-06 18:54:47 +01:00
|
|
|
def VReg_512 : RegisterClass<"AMDGPU", [v16i32, v16f32], 32, (add VGPR_512)> {
|
2016-09-03 19:25:44 +02:00
|
|
|
let Size = 512;
|
2015-09-26 06:09:34 +02:00
|
|
|
let CopyCost = 16;
|
2016-05-21 05:55:07 +02:00
|
|
|
let AllocationPriority = 6;
|
2015-09-26 06:09:34 +02:00
|
|
|
}
|
2013-02-26 18:52:03 +01:00
|
|
|
|
2015-02-14 04:54:32 +01:00
|
|
|
def VReg_1 : RegisterClass<"AMDGPU", [i1], 32, (add VGPR_32)> {
|
|
|
|
let Size = 32;
|
|
|
|
}
|
2014-04-30 17:31:33 +02:00
|
|
|
|
2017-02-27 19:49:11 +01:00
|
|
|
def VS_32 : RegisterClass<"AMDGPU", [i32, f32, i16, f16, v2i16, v2f16], 32,
|
2016-11-13 08:01:11 +01:00
|
|
|
(add VGPR_32, SReg_32)> {
|
2016-09-07 08:16:45 +02:00
|
|
|
let isAllocatable = 0;
|
|
|
|
}
|
2016-07-21 15:29:57 +02:00
|
|
|
|
|
|
|
def VS_64 : RegisterClass<"AMDGPU", [i64, f64], 32, (add VReg_64, SReg_64)> {
|
2016-09-07 08:16:45 +02:00
|
|
|
let isAllocatable = 0;
|
2016-07-21 15:29:57 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Register operands
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
class RegImmMatcher<string name> : AsmOperandClass {
|
|
|
|
let Name = name;
|
|
|
|
let RenderMethod = "addRegOrImmOperands";
|
|
|
|
}
|
|
|
|
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 16:44:04 +02:00
|
|
|
multiclass SIRegOperand <string rc, string MatchName, string opType> {
|
|
|
|
let OperandNamespace = "AMDGPU" in {
|
2016-12-10 01:39:12 +01:00
|
|
|
def _b16 : RegisterOperand<!cast<RegisterClass>(rc#"_32")> {
|
|
|
|
let OperandType = opType#"_INT16";
|
|
|
|
let ParserMatchClass = RegImmMatcher<MatchName#"B16">;
|
|
|
|
let DecoderMethod = "decodeOperand_VSrc16";
|
|
|
|
}
|
|
|
|
|
|
|
|
def _f16 : RegisterOperand<!cast<RegisterClass>(rc#"_32")> {
|
|
|
|
let OperandType = opType#"_FP16";
|
|
|
|
let ParserMatchClass = RegImmMatcher<MatchName#"F16">;
|
|
|
|
let DecoderMethod = "decodeOperand_VSrc16";
|
|
|
|
}
|
2016-11-01 01:55:14 +01:00
|
|
|
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 16:44:04 +02:00
|
|
|
def _b32 : RegisterOperand<!cast<RegisterClass>(rc#"_32")> {
|
2016-12-10 01:39:12 +01:00
|
|
|
let OperandType = opType#"_INT32";
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 16:44:04 +02:00
|
|
|
let ParserMatchClass = RegImmMatcher<MatchName#"B32">;
|
|
|
|
}
|
2016-11-01 01:55:14 +01:00
|
|
|
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 16:44:04 +02:00
|
|
|
def _f32 : RegisterOperand<!cast<RegisterClass>(rc#"_32")> {
|
2016-12-10 01:39:12 +01:00
|
|
|
let OperandType = opType#"_FP32";
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 16:44:04 +02:00
|
|
|
let ParserMatchClass = RegImmMatcher<MatchName#"F32">;
|
|
|
|
}
|
2016-11-01 01:55:14 +01:00
|
|
|
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 16:44:04 +02:00
|
|
|
def _b64 : RegisterOperand<!cast<RegisterClass>(rc#"_64")> {
|
2016-12-10 01:39:12 +01:00
|
|
|
let OperandType = opType#"_INT64";
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 16:44:04 +02:00
|
|
|
let ParserMatchClass = RegImmMatcher<MatchName#"B64">;
|
|
|
|
}
|
|
|
|
|
|
|
|
def _f64 : RegisterOperand<!cast<RegisterClass>(rc#"_64")> {
|
2016-12-10 01:39:12 +01:00
|
|
|
let OperandType = opType#"_FP64";
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 16:44:04 +02:00
|
|
|
let ParserMatchClass = RegImmMatcher<MatchName#"F64">;
|
|
|
|
}
|
2017-02-27 19:49:11 +01:00
|
|
|
|
|
|
|
def _v2b16 : RegisterOperand<!cast<RegisterClass>(rc#"_32")> {
|
|
|
|
let OperandType = opType#"_V2INT16";
|
|
|
|
let ParserMatchClass = RegImmMatcher<MatchName#"V2B16">;
|
|
|
|
let DecoderMethod = "decodeOperand_VSrcV216";
|
|
|
|
}
|
|
|
|
|
|
|
|
def _v2f16 : RegisterOperand<!cast<RegisterClass>(rc#"_32")> {
|
|
|
|
let OperandType = opType#"_V2FP16";
|
|
|
|
let ParserMatchClass = RegImmMatcher<MatchName#"V2F16">;
|
|
|
|
let DecoderMethod = "decodeOperand_VSrcV216";
|
|
|
|
}
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 16:44:04 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-12-10 01:39:12 +01:00
|
|
|
// FIXME: 64-bit sources can sometimes use 32-bit constants.
|
2016-11-01 01:55:14 +01:00
|
|
|
multiclass RegImmOperand <string rc, string MatchName>
|
2016-12-10 01:39:12 +01:00
|
|
|
: SIRegOperand<rc, MatchName, "OPERAND_REG_IMM">;
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 16:44:04 +02:00
|
|
|
|
2016-11-01 01:55:14 +01:00
|
|
|
multiclass RegInlineOperand <string rc, string MatchName>
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 16:44:04 +02:00
|
|
|
: SIRegOperand<rc, MatchName, "OPERAND_REG_INLINE_C">;
|
|
|
|
|
2013-02-26 18:52:03 +01:00
|
|
|
//===----------------------------------------------------------------------===//
|
2014-09-23 23:26:25 +02:00
|
|
|
// SSrc_* Operands with an SGPR or a 32-bit immediate
|
2013-02-26 18:52:03 +01:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 16:44:04 +02:00
|
|
|
defm SSrc : RegImmOperand<"SReg", "SSrc">;
|
2013-02-26 18:52:03 +01:00
|
|
|
|
2014-09-23 23:26:25 +02:00
|
|
|
//===----------------------------------------------------------------------===//
|
2014-12-19 23:15:30 +01:00
|
|
|
// SCSrc_* Operands with an SGPR or a inline constant
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 16:44:04 +02:00
|
|
|
defm SCSrc : RegInlineOperand<"SReg", "SCSrc"> ;
|
2016-07-21 15:29:57 +02:00
|
|
|
|
2014-12-19 23:15:30 +01:00
|
|
|
//===----------------------------------------------------------------------===//
|
2014-09-23 23:26:25 +02:00
|
|
|
// VSrc_* Operands with an SGPR, VGPR or a 32-bit immediate
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 16:44:04 +02:00
|
|
|
defm VSrc : RegImmOperand<"VS", "VSrc">;
|
2012-12-11 22:25:42 +01:00
|
|
|
|
2016-09-09 21:31:51 +02:00
|
|
|
def VSrc_128 : RegisterOperand<VReg_128>;
|
|
|
|
|
2016-07-19 02:35:03 +02:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// VSrc_* Operands with an VGPR
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
// This is for operands with the enum(9), VSrc encoding restriction,
|
|
|
|
// but only allows VGPRs.
|
|
|
|
def VRegSrc_32 : RegisterOperand<VGPR_32> {
|
|
|
|
//let ParserMatchClass = RegImmMatcher<"VRegSrc32">;
|
|
|
|
let DecoderMethod = "DecodeVS_32RegisterClass";
|
|
|
|
}
|
|
|
|
|
2014-09-23 23:26:25 +02:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// VCSrc_* Operands with an SGPR, VGPR or an inline constant
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
AMDGPU] Assembler: better support for immediate literals in assembler.
Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.
With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
- We parsed fp literal:
- Instruction expects 64-bit operand:
- If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
- then we do nothing this literal
- Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
- report error
- Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
- If instruction expect fp operand type (f64)
- Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
- If so then do nothing
- Else (e.g. v_fract_f64 v[0:1], 3.1415)
- report warning that low 32 bits will be set to zeroes and precision will be lost
- set low 32 bits of literal to zeroes
- Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
- report error as it is unclear how to encode this literal
- Instruction expects 32-bit operand:
- Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
- Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
- do nothing
- Else report error
- Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
- Parsed binary literal:
- Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
- do nothing
- Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
- report error
- Else, literal is not-inlinable and we are not required to inline it
- Are high 32 bit of literal zeroes or same as sign bit (32 bit)
- do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
- Else
- report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)
For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
OPERAND_REG_IMM32_INT,
OPERAND_REG_IMM32_FP,
OPERAND_REG_INLINE_C_INT,
OPERAND_REG_INLINE_C_FP,
}
'''
This is not working yet:
- Several tests are failing
- Problems with predicate methods for inline immediates
- LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.
Reviewers: vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, artem.tamazov
Differential Revision: https://reviews.llvm.org/D22922
llvm-svn: 281050
2016-09-09 16:44:04 +02:00
|
|
|
defm VCSrc : RegInlineOperand<"VS", "VCSrc">;
|