RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-26 04:32:44 +01:00
Code Issues Projects Releases Wiki Activity
97e89dc154
llvm-mirror/test/TableGen/dag-isel-subregs.td

15 lines
601 B
TableGen
Raw Normal View History

[TBLGEN] Fix subreg value overflow in DAGISelMatcher Tablegen's DAGISelMatcher emits integers in a VBR format, so if an integer is below 128 it can fit into a single byte, otherwise high bit is set, next byte is used etc. MatcherTable is essentially an unsigned char table. When SelectionDAGISel parses the table it does a reverse translation. In a situation when numeric value of an integer to emit is unknown it can be emitted not as OPC_EmitInteger but as OPC_EmitStringInteger using a symbolic name of the value. In this situation the value should not exceed 127. One of the situations when OPC_EmitStringInteger is used is if we need to emit a subreg into a matcher table. However, number of subregs can exceed 127. Currently last defined subreg for AMDGPU is 192. That results in a silent bug in the ISel with matcher reading from an invalid offset. Fixed this bug to emit actual VBR encoded value for a subregs which value exceeds 127. Differential Revision: https://reviews.llvm.org/D74368
2020-02-10 22:37:00 +01:00
// RUN: llvm-tblgen -gen-dag-isel -I %p/../../include -I %p/Common %s | FileCheck %s
include "reg-with-subregs-common.td"
// CHECK-LABEL: OPC_CheckOpcode, TARGET_VAL(ISD::EXTRACT_SUBVECTOR),
// CHECK: OPC_CheckChild1Integer, 0,
// CHECK: OPC_EmitInteger, MVT::i32, sub0_sub1,
def : Pat<(v2i32 (extract_subvector v32i32:$src, (i32 0))),
(EXTRACT_SUBREG GPR_1024:$src, sub0_sub1)>;
[TableGen][SelectionDAG] Improve efficiency of encoding negative immediates for isel's CheckInteger opcode. CheckInteger uses an int64_t encoded using a variable width encoding that is optimized for encoding a number with a lot of leading zeros. Negative numbers have no leading zeros so use the largest encoding requiring 9 bytes. I believe its most like we want to check for positive and negative numbers near 0. -1 is quite common due to its use in the 'not' idiom. To optimize for this, we can borrow an idea from the bitcode format and move the sign bit to bit 0 with the magnitude stored in the upper bits. This will drastically increase the number of leading zeros for small magnitudes. Then we can run this value through VBR encoding. This gives a small reduction in the table size on all in tree targets except VE where size increased by about 300 bytes due to intrinsic ids now requiring 3 bytes instead of 2. Since the intrinsic enum space is shared by all targets this an unfortunate consquence of where VE is currently located in the range. Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D96317
2021-02-18 17:45:08 +01:00
// CHECK: OPC_CheckChild1Integer, 30,
[TBLGEN] Fix subreg value overflow in DAGISelMatcher Tablegen's DAGISelMatcher emits integers in a VBR format, so if an integer is below 128 it can fit into a single byte, otherwise high bit is set, next byte is used etc. MatcherTable is essentially an unsigned char table. When SelectionDAGISel parses the table it does a reverse translation. In a situation when numeric value of an integer to emit is unknown it can be emitted not as OPC_EmitInteger but as OPC_EmitStringInteger using a symbolic name of the value. In this situation the value should not exceed 127. One of the situations when OPC_EmitStringInteger is used is if we need to emit a subreg into a matcher table. However, number of subregs can exceed 127. Currently last defined subreg for AMDGPU is 192. That results in a silent bug in the ISel with matcher reading from an invalid offset. Fixed this bug to emit actual VBR encoded value for a subregs which value exceeds 127. Differential Revision: https://reviews.llvm.org/D74368
2020-02-10 22:37:00 +01:00
// CHECK: OPC_EmitInteger, MVT::i32, 5|128,1/*133*/,
def : Pat<(v2i32 (extract_subvector v32i32:$src, (i32 15))),
(EXTRACT_SUBREG GPR_1024:$src, sub30_sub31)>;
Reference in New Issue Copy Permalink