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.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2017-12-22 16:18:06 +01:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Helpers
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
class getSubRegs<int size> {
|
|
|
|
list<SubRegIndex> ret2 = [sub0, sub1];
|
|
|
|
list<SubRegIndex> ret3 = [sub0, sub1, sub2];
|
|
|
|
list<SubRegIndex> ret4 = [sub0, sub1, sub2, sub3];
|
|
|
|
list<SubRegIndex> ret8 = [sub0, sub1, sub2, sub3, sub4, sub5, sub6, sub7];
|
|
|
|
list<SubRegIndex> ret16 = [sub0, sub1, sub2, sub3,
|
|
|
|
sub4, sub5, sub6, sub7,
|
|
|
|
sub8, sub9, sub10, sub11,
|
|
|
|
sub12, sub13, sub14, sub15];
|
|
|
|
|
|
|
|
list<SubRegIndex> ret = !if(!eq(size, 2), ret2,
|
|
|
|
!if(!eq(size, 3), ret3,
|
|
|
|
!if(!eq(size, 4), ret4,
|
|
|
|
!if(!eq(size, 8), ret8, ret16))));
|
|
|
|
}
|
|
|
|
|
2013-02-26 18:52:03 +01:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// 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>;
|
|
|
|
|
2017-07-18 18:44:56 +02:00
|
|
|
// Pseudo-registers: Used as placeholders during isel and immediately
|
|
|
|
// replaced, never seeing the verifier.
|
|
|
|
def PRIVATE_RSRC_REG : SIReg<"", 0>;
|
|
|
|
def FP_REG : SIReg<"", 0>;
|
|
|
|
def SP_REG : SIReg<"", 0>;
|
|
|
|
def SCRATCH_WAVE_OFFSET_REG : SIReg<"", 0>;
|
|
|
|
|
2014-03-17 18:03:51 +01:00
|
|
|
// 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;
|
|
|
|
}
|
|
|
|
|
2017-12-11 16:23:20 +01:00
|
|
|
foreach Index = 0-15 in {
|
|
|
|
def TTMP#Index#_vi : SIReg<"ttmp"#Index, !add(112, Index)>;
|
|
|
|
def TTMP#Index#_gfx9 : SIReg<"ttmp"#Index, !add(108, Index)>;
|
|
|
|
def TTMP#Index : SIReg<"", 0>;
|
|
|
|
}
|
2016-04-13 18:18:41 +02:00
|
|
|
|
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
|
2017-12-22 16:18:06 +01:00
|
|
|
def SGPR_64Regs : RegisterTuples<getSubRegs<2>.ret,
|
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
|
2017-12-22 16:18:06 +01:00
|
|
|
def SGPR_128Regs : RegisterTuples<getSubRegs<4>.ret,
|
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
|
2017-12-22 16:18:06 +01:00
|
|
|
def SGPR_256Regs : RegisterTuples<getSubRegs<8>.ret,
|
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
|
2017-12-22 16:18:06 +01:00
|
|
|
def SGPR_512Regs : RegisterTuples<getSubRegs<16>.ret,
|
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,
|
2017-12-11 16:23:20 +01:00
|
|
|
(add (sequence "TTMP%u", 0, 15))> {
|
2016-04-13 18:18:41 +02:00
|
|
|
let isAllocatable = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Trap handler TMP 64-bit registers
|
2017-12-22 16:18:06 +01:00
|
|
|
def TTMP_64Regs : RegisterTuples<getSubRegs<2>.ret,
|
2016-04-13 18:18:41 +02:00
|
|
|
[(add (decimate TTMP_32, 2)),
|
|
|
|
(add (decimate (shl TTMP_32, 1), 2))]>;
|
|
|
|
|
|
|
|
// Trap handler TMP 128-bit registers
|
2017-12-22 16:18:06 +01:00
|
|
|
def TTMP_128Regs : RegisterTuples<getSubRegs<4>.ret,
|
2016-04-13 18:18:41 +02:00
|
|
|
[(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))]>;
|
|
|
|
|
2017-12-22 16:18:06 +01:00
|
|
|
def TTMP_256Regs : RegisterTuples<getSubRegs<8>.ret,
|
|
|
|
[(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)),
|
|
|
|
(add (decimate (shl TTMP_32, 4), 4)),
|
|
|
|
(add (decimate (shl TTMP_32, 5), 4)),
|
|
|
|
(add (decimate (shl TTMP_32, 6), 4)),
|
|
|
|
(add (decimate (shl TTMP_32, 7), 4))]>;
|
|
|
|
|
|
|
|
def TTMP_512Regs : RegisterTuples<getSubRegs<16>.ret,
|
|
|
|
[(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)),
|
|
|
|
(add (decimate (shl TTMP_32, 4), 4)),
|
|
|
|
(add (decimate (shl TTMP_32, 5), 4)),
|
|
|
|
(add (decimate (shl TTMP_32, 6), 4)),
|
|
|
|
(add (decimate (shl TTMP_32, 7), 4)),
|
|
|
|
(add (decimate (shl TTMP_32, 8), 4)),
|
|
|
|
(add (decimate (shl TTMP_32, 9), 4)),
|
|
|
|
(add (decimate (shl TTMP_32, 10), 4)),
|
|
|
|
(add (decimate (shl TTMP_32, 11), 4)),
|
|
|
|
(add (decimate (shl TTMP_32, 12), 4)),
|
|
|
|
(add (decimate (shl TTMP_32, 13), 4)),
|
|
|
|
(add (decimate (shl TTMP_32, 14), 4)),
|
|
|
|
(add (decimate (shl TTMP_32, 15), 4))]>;
|
|
|
|
|
|
|
|
class TmpRegTuplesBase<int index, int size,
|
|
|
|
list<Register> subRegs,
|
|
|
|
list<SubRegIndex> indices = getSubRegs<size>.ret,
|
|
|
|
int index1 = !add(index, !add(size, -1)),
|
|
|
|
string name = "ttmp["#index#":"#index1#"]"> :
|
|
|
|
RegisterWithSubRegs<name, subRegs> {
|
|
|
|
let HWEncoding = subRegs[0].HWEncoding;
|
|
|
|
let SubRegIndices = indices;
|
|
|
|
}
|
|
|
|
|
|
|
|
class TmpRegTuples<string tgt,
|
|
|
|
int size,
|
|
|
|
int index0,
|
|
|
|
int index1 = !add(index0, 1),
|
|
|
|
int index2 = !add(index0, !if(!eq(size, 2), 1, 2)),
|
|
|
|
int index3 = !add(index0, !if(!eq(size, 2), 1, 3)),
|
|
|
|
int index4 = !add(index0, !if(!eq(size, 8), 4, 1)),
|
|
|
|
int index5 = !add(index0, !if(!eq(size, 8), 5, 1)),
|
|
|
|
int index6 = !add(index0, !if(!eq(size, 8), 6, 1)),
|
|
|
|
int index7 = !add(index0, !if(!eq(size, 8), 7, 1)),
|
|
|
|
Register r0 = !cast<Register>("TTMP"#index0#tgt),
|
|
|
|
Register r1 = !cast<Register>("TTMP"#index1#tgt),
|
|
|
|
Register r2 = !cast<Register>("TTMP"#index2#tgt),
|
|
|
|
Register r3 = !cast<Register>("TTMP"#index3#tgt),
|
|
|
|
Register r4 = !cast<Register>("TTMP"#index4#tgt),
|
|
|
|
Register r5 = !cast<Register>("TTMP"#index5#tgt),
|
|
|
|
Register r6 = !cast<Register>("TTMP"#index6#tgt),
|
|
|
|
Register r7 = !cast<Register>("TTMP"#index7#tgt)> :
|
|
|
|
TmpRegTuplesBase<index0, size,
|
|
|
|
!if(!eq(size, 2), [r0, r1],
|
|
|
|
!if(!eq(size, 4), [r0, r1, r2, r3],
|
|
|
|
[r0, r1, r2, r3, r4, r5, r6, r7])),
|
|
|
|
getSubRegs<size>.ret>;
|
2017-12-11 16:23:20 +01:00
|
|
|
|
|
|
|
foreach Index = {0, 2, 4, 6, 8, 10, 12, 14} in {
|
2017-12-22 16:18:06 +01:00
|
|
|
def TTMP#Index#_TTMP#!add(Index,1)#_vi : TmpRegTuples<"_vi", 2, Index>;
|
|
|
|
def TTMP#Index#_TTMP#!add(Index,1)#_gfx9 : TmpRegTuples<"_gfx9", 2, Index>;
|
2017-12-11 16:23:20 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
foreach Index = {0, 4, 8, 12} in {
|
|
|
|
def TTMP#Index#_TTMP#!add(Index,1)#
|
|
|
|
_TTMP#!add(Index,2)#
|
2017-12-22 16:18:06 +01:00
|
|
|
_TTMP#!add(Index,3)#_vi : TmpRegTuples<"_vi", 4, Index>;
|
2017-12-11 16:23:20 +01:00
|
|
|
def TTMP#Index#_TTMP#!add(Index,1)#
|
|
|
|
_TTMP#!add(Index,2)#
|
2017-12-22 16:18:06 +01:00
|
|
|
_TTMP#!add(Index,3)#_gfx9 : TmpRegTuples<"_gfx9", 4, Index>;
|
2017-12-11 16:23:20 +01:00
|
|
|
}
|
|
|
|
|
2017-12-22 16:18:06 +01:00
|
|
|
foreach Index = {0, 4, 8} in {
|
|
|
|
def TTMP#Index#_TTMP#!add(Index,1)#
|
|
|
|
_TTMP#!add(Index,2)#
|
|
|
|
_TTMP#!add(Index,3)#
|
|
|
|
_TTMP#!add(Index,4)#
|
|
|
|
_TTMP#!add(Index,5)#
|
|
|
|
_TTMP#!add(Index,6)#
|
|
|
|
_TTMP#!add(Index,7)#_vi : TmpRegTuples<"_vi", 8, Index>;
|
|
|
|
def TTMP#Index#_TTMP#!add(Index,1)#
|
|
|
|
_TTMP#!add(Index,2)#
|
|
|
|
_TTMP#!add(Index,3)#
|
|
|
|
_TTMP#!add(Index,4)#
|
|
|
|
_TTMP#!add(Index,5)#
|
|
|
|
_TTMP#!add(Index,6)#
|
|
|
|
_TTMP#!add(Index,7)#_gfx9 : TmpRegTuples<"_gfx9", 8, Index>;
|
|
|
|
}
|
|
|
|
|
|
|
|
def TTMP0_TTMP1_TTMP2_TTMP3_TTMP4_TTMP5_TTMP6_TTMP7_TTMP8_TTMP9_TTMP10_TTMP11_TTMP12_TTMP13_TTMP14_TTMP15_vi :
|
|
|
|
TmpRegTuplesBase<0, 16,
|
|
|
|
[TTMP0_vi, TTMP1_vi, TTMP2_vi, TTMP3_vi,
|
|
|
|
TTMP4_vi, TTMP5_vi, TTMP6_vi, TTMP7_vi,
|
|
|
|
TTMP8_vi, TTMP9_vi, TTMP10_vi, TTMP11_vi,
|
|
|
|
TTMP12_vi, TTMP13_vi, TTMP14_vi, TTMP15_vi]>;
|
|
|
|
|
|
|
|
def TTMP0_TTMP1_TTMP2_TTMP3_TTMP4_TTMP5_TTMP6_TTMP7_TTMP8_TTMP9_TTMP10_TTMP11_TTMP12_TTMP13_TTMP14_TTMP15_gfx9 :
|
|
|
|
TmpRegTuplesBase<0, 16,
|
|
|
|
[TTMP0_gfx9, TTMP1_gfx9, TTMP2_gfx9, TTMP3_gfx9,
|
|
|
|
TTMP4_gfx9, TTMP5_gfx9, TTMP6_gfx9, TTMP7_gfx9,
|
|
|
|
TTMP8_gfx9, TTMP9_gfx9, TTMP10_gfx9, TTMP11_gfx9,
|
|
|
|
TTMP12_gfx9, TTMP13_gfx9, TTMP14_gfx9, TTMP15_gfx9]>;
|
|
|
|
|
|
|
|
|
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
|
2017-12-22 16:18:06 +01:00
|
|
|
def VGPR_64 : RegisterTuples<getSubRegs<2>.ret,
|
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
|
2017-12-22 16:18:06 +01:00
|
|
|
def VGPR_96 : RegisterTuples<getSubRegs<3>.ret,
|
2013-04-10 10:39:16 +02:00
|
|
|
[(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
|
2017-12-22 16:18:06 +01:00
|
|
|
def VGPR_128 : RegisterTuples<getSubRegs<4>.ret,
|
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
|
2017-12-22 16:18:06 +01:00
|
|
|
def VGPR_256 : RegisterTuples<getSubRegs<8>.ret,
|
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
|
2017-12-22 16:18:06 +01:00
|
|
|
def VGPR_512 : RegisterTuples<getSubRegs<16>.ret,
|
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
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2017-08-01 21:54:18 +02:00
|
|
|
def Pseudo_SReg_32 : RegisterClass<"AMDGPU", [i32, f32, i16, f16, v2i16, v2f16], 32,
|
|
|
|
(add FP_REG, SP_REG, SCRATCH_WAVE_OFFSET_REG)> {
|
|
|
|
let isAllocatable = 0;
|
|
|
|
let CopyCost = -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
def Pseudo_SReg_128 : RegisterClass<"AMDGPU", [v4i32, v2i64], 32,
|
|
|
|
(add PRIVATE_RSRC_REG)> {
|
|
|
|
let isAllocatable = 0;
|
|
|
|
let CopyCost = -1;
|
|
|
|
}
|
|
|
|
|
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,
|
2017-07-24 20:06:15 +02:00
|
|
|
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-07-21 17:36:16 +02:00
|
|
|
def SReg_32_XEXEC_HI : RegisterClass<"AMDGPU", [i32, f32, i16, f16, v2i16, v2f16], 32,
|
|
|
|
(add SReg_32_XM0_XEXEC, EXEC_LO, M0_CLASS)> {
|
|
|
|
let AllocationPriority = 7;
|
|
|
|
}
|
|
|
|
|
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,
|
2017-07-21 17:36:16 +02:00
|
|
|
(add SReg_32_XM0, M0_CLASS, EXEC_LO, EXEC_HI, SReg_32_XEXEC_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
|
|
|
|
2017-07-18 18:44:56 +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
|
|
|
|
|
2017-12-22 16:18:06 +01:00
|
|
|
def SGPR_256 : RegisterClass<"AMDGPU", [v8i32, v8f32], 32, (add SGPR_256Regs)> {
|
|
|
|
let AllocationPriority = 11;
|
|
|
|
}
|
|
|
|
|
|
|
|
def TTMP_256 : RegisterClass<"AMDGPU", [v8i32, v8f32], 32, (add TTMP_256Regs)> {
|
|
|
|
let isAllocatable = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
def SReg_256 : RegisterClass<"AMDGPU", [v8i32, v8f32], 32,
|
|
|
|
(add SGPR_256, TTMP_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-12-22 16:18:06 +01:00
|
|
|
def SGPR_512 : RegisterClass<"AMDGPU", [v16i32, v16f32], 32, (add SGPR_512Regs)> {
|
|
|
|
let AllocationPriority = 12;
|
|
|
|
}
|
|
|
|
|
|
|
|
def TTMP_512 : RegisterClass<"AMDGPU", [v16i32, v16f32], 32, (add TTMP_512Regs)> {
|
|
|
|
let isAllocatable = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
def SReg_512 : RegisterClass<"AMDGPU", [v16i32, v16f32], 32,
|
|
|
|
(add SGPR_512, TTMP_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
|
|
|
|
AMDGPU: VALU carry-in and v_cndmask condition cannot be EXEC
The hardware will only forward EXEC_LO; the high 32 bits will be zero.
Additionally, inline constants do not work. At least,
v_addc_u32_e64 v0, vcc, v0, v1, -1
which could conceivably be used to combine (v0 + v1 + 1) into a single
instruction, acts as if all carry-in bits are zero.
The llvm.amdgcn.ps.live test is adjusted; it would be nice to combine
s_mov_b64 s[0:1], exec
v_cndmask_b32_e64 v0, v1, v2, s[0:1]
into
v_mov_b32 v0, v3
but it's not particularly high priority.
Fixes dEQP-GLES31.functional.shaders.helper_invocation.value.*
llvm-svn: 314522
2017-09-29 17:37:31 +02:00
|
|
|
def SCSrc_i1 : RegisterOperand<SReg_64_XEXEC>;
|
|
|
|
|
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
|
|
|
|
2017-07-18 15:12:48 +02:00
|
|
|
def VSrc_128 : RegisterOperand<VReg_128> {
|
|
|
|
let DecoderMethod = "DecodeVS_128RegisterClass";
|
|
|
|
}
|
2016-09-09 21:31:51 +02:00
|
|
|
|
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">;
|