RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-23 03:02:36 +01:00
Code Issues Projects Releases Wiki Activity
b215117634
llvm-mirror/unittests/Target/ARM/MachineInstrTest.cpp

1211 lines
31 KiB
C++
Raw Normal View History

[ARM][MVE] Add invalidForTailPredication to TSFlags Set this bit for the MVE reduction instructions to prevent a loop from becoming tail predicated in their presence. Differential Revision: https://reviews.llvm.org/D67444 llvm-svn: 372076
2019-09-17 09:43:04 +02:00
#include "ARMBaseInstrInfo.h"
#include "ARMSubtarget.h"
#include "ARMTargetMachine.h"
#include "llvm/Support/TargetRegistry.h"
#include "llvm/Support/TargetSelect.h"
#include "llvm/Target/TargetMachine.h"
#include "llvm/Target/TargetOptions.h"
#include "gtest/gtest.h"
using namespace llvm;
[ARM][MVE] Add DoubleWidthResult flag Add a flag for those instructions which read from the top/bottom halves of their inputs and produce a vector of results with double width elements. Differential Revision: https://reviews.llvm.org/D76762
2020-03-27 14:38:54 +01:00
TEST(MachineInstructionDoubleWidthResult, IsCorrect) {
using namespace ARM;
auto DoubleWidthResult = [](unsigned Opcode) {
switch (Opcode) {
default:
break;
case MVE_VMULLBp16:
case MVE_VMULLBp8:
case MVE_VMULLBs16:
case MVE_VMULLBs32:
case MVE_VMULLBs8:
case MVE_VMULLBu16:
case MVE_VMULLBu32:
case MVE_VMULLBu8:
case MVE_VMULLTp16:
case MVE_VMULLTp8:
case MVE_VMULLTs16:
case MVE_VMULLTs32:
case MVE_VMULLTs8:
case MVE_VMULLTu16:
case MVE_VMULLTu32:
case MVE_VMULLTu8:
case MVE_VQDMULL_qr_s16bh:
case MVE_VQDMULL_qr_s16th:
case MVE_VQDMULL_qr_s32bh:
case MVE_VQDMULL_qr_s32th:
case MVE_VQDMULLs16bh:
case MVE_VQDMULLs16th:
case MVE_VQDMULLs32bh:
case MVE_VQDMULLs32th:
case MVE_VMOVLs16bh:
case MVE_VMOVLs16th:
case MVE_VMOVLs8bh:
case MVE_VMOVLs8th:
case MVE_VMOVLu16bh:
case MVE_VMOVLu16th:
case MVE_VMOVLu8bh:
case MVE_VMOVLu8th:
case MVE_VSHLL_imms16bh:
case MVE_VSHLL_imms16th:
case MVE_VSHLL_imms8bh:
case MVE_VSHLL_imms8th:
case MVE_VSHLL_immu16bh:
case MVE_VSHLL_immu16th:
case MVE_VSHLL_immu8bh:
case MVE_VSHLL_immu8th:
case MVE_VSHLL_lws16bh:
case MVE_VSHLL_lws16th:
case MVE_VSHLL_lws8bh:
case MVE_VSHLL_lws8th:
case MVE_VSHLL_lwu16bh:
case MVE_VSHLL_lwu16th:
case MVE_VSHLL_lwu8bh:
case MVE_VSHLL_lwu8th:
return true;
}
return false;
};
LLVMInitializeARMTargetInfo();
LLVMInitializeARMTarget();
LLVMInitializeARMTargetMC();
[ARM] Replace arm vendor with none. NFC
2020-04-22 17:33:11 +02:00
auto TT(Triple::normalize("thumbv8.1m.main-none-none-eabi"));
[ARM][MVE] Add DoubleWidthResult flag Add a flag for those instructions which read from the top/bottom halves of their inputs and produce a vector of results with double width elements. Differential Revision: https://reviews.llvm.org/D76762
2020-03-27 14:38:54 +01:00
std::string Error;
const Target *T = TargetRegistry::lookupTarget(TT, Error);
if (!T) {
dbgs() << Error;
return;
}
TargetOptions Options;
auto TM = std::unique_ptr<LLVMTargetMachine>(
static_cast<LLVMTargetMachine*>(
T->createTargetMachine(TT, "generic", "", Options, None, None,
CodeGenOpt::Default)));
ARMSubtarget ST(TM->getTargetTriple(), std::string(TM->getTargetCPU()),
std::string(TM->getTargetFeatureString()),
*static_cast<const ARMBaseTargetMachine *>(TM.get()), false);
const ARMBaseInstrInfo *TII = ST.getInstrInfo();
auto MII = TM->getMCInstrInfo();
for (unsigned i = 0; i < ARM::INSTRUCTION_LIST_END; ++i) {
const MCInstrDesc &Desc = TII->get(i);
uint64_t Flags = Desc.TSFlags;
if ((Flags & ARMII::DomainMask) != ARMII::DomainMVE)
continue;
bool Valid = (Flags & ARMII::DoubleWidthResult) != 0;
ASSERT_EQ(DoubleWidthResult(i), Valid)
<< MII->getName(i)
<< ": mismatched expectation for tail-predicated safety\n";
}
}
[ARM][MVE] Add HorizontalReduction flag Add a target flag for instructions that reduce into one, or more, scalar reg(s), including variants of: - VADDV - VABAV - VMINV/VMAXV - VMLADAV Differential Revision: https://reviews.llvm.org/D76683
2020-03-25 12:12:03 +01:00
TEST(MachineInstructionHorizontalReduction, IsCorrect) {
using namespace ARM;
auto HorizontalReduction = [](unsigned Opcode) {
switch (Opcode) {
default:
break;
case MVE_VABAVs16:
case MVE_VABAVs32:
case MVE_VABAVs8:
case MVE_VABAVu16:
case MVE_VABAVu32:
case MVE_VABAVu8:
case MVE_VADDLVs32acc:
case MVE_VADDLVs32no_acc:
case MVE_VADDLVu32acc:
case MVE_VADDLVu32no_acc:
case MVE_VADDVs16acc:
case MVE_VADDVs16no_acc:
case MVE_VADDVs32acc:
case MVE_VADDVs32no_acc:
case MVE_VADDVs8acc:
case MVE_VADDVs8no_acc:
case MVE_VADDVu16acc:
case MVE_VADDVu16no_acc:
case MVE_VADDVu32acc:
case MVE_VADDVu32no_acc:
case MVE_VADDVu8acc:
case MVE_VADDVu8no_acc:
case MVE_VMAXAVs16:
case MVE_VMAXAVs32:
case MVE_VMAXAVs8:
case MVE_VMAXNMAVf16:
case MVE_VMAXNMAVf32:
case MVE_VMAXNMVf16:
case MVE_VMAXNMVf32:
case MVE_VMAXVs16:
case MVE_VMAXVs32:
case MVE_VMAXVs8:
case MVE_VMAXVu16:
case MVE_VMAXVu32:
case MVE_VMAXVu8:
case MVE_VMINAVs16:
case MVE_VMINAVs32:
case MVE_VMINAVs8:
case MVE_VMINNMAVf16:
case MVE_VMINNMAVf32:
case MVE_VMINNMVf16:
case MVE_VMINNMVf32:
case MVE_VMINVs16:
case MVE_VMINVs32:
case MVE_VMINVs8:
case MVE_VMINVu16:
case MVE_VMINVu32:
case MVE_VMINVu8:
case MVE_VMLADAVas16:
case MVE_VMLADAVas32:
case MVE_VMLADAVas8:
case MVE_VMLADAVau16:
case MVE_VMLADAVau32:
case MVE_VMLADAVau8:
case MVE_VMLADAVaxs16:
case MVE_VMLADAVaxs32:
case MVE_VMLADAVaxs8:
case MVE_VMLADAVs16:
case MVE_VMLADAVs32:
case MVE_VMLADAVs8:
case MVE_VMLADAVu16:
case MVE_VMLADAVu32:
case MVE_VMLADAVu8:
case MVE_VMLADAVxs16:
case MVE_VMLADAVxs32:
case MVE_VMLADAVxs8:
case MVE_VMLALDAVas16:
case MVE_VMLALDAVas32:
case MVE_VMLALDAVau16:
case MVE_VMLALDAVau32:
case MVE_VMLALDAVaxs16:
case MVE_VMLALDAVaxs32:
case MVE_VMLALDAVs16:
case MVE_VMLALDAVs32:
case MVE_VMLALDAVu16:
case MVE_VMLALDAVu32:
case MVE_VMLALDAVxs16:
case MVE_VMLALDAVxs32:
case MVE_VMLSDAVas16:
case MVE_VMLSDAVas32:
case MVE_VMLSDAVas8:
case MVE_VMLSDAVaxs16:
case MVE_VMLSDAVaxs32:
case MVE_VMLSDAVaxs8:
case MVE_VMLSDAVs16:
case MVE_VMLSDAVs32:
case MVE_VMLSDAVs8:
case MVE_VMLSDAVxs16:
case MVE_VMLSDAVxs32:
case MVE_VMLSDAVxs8:
case MVE_VMLSLDAVas16:
case MVE_VMLSLDAVas32:
case MVE_VMLSLDAVaxs16:
case MVE_VMLSLDAVaxs32:
case MVE_VMLSLDAVs16:
case MVE_VMLSLDAVs32:
case MVE_VMLSLDAVxs16:
case MVE_VMLSLDAVxs32:
case MVE_VRMLALDAVHas32:
case MVE_VRMLALDAVHau32:
case MVE_VRMLALDAVHaxs32:
case MVE_VRMLALDAVHs32:
case MVE_VRMLALDAVHu32:
case MVE_VRMLALDAVHxs32:
case MVE_VRMLSLDAVHas32:
case MVE_VRMLSLDAVHaxs32:
case MVE_VRMLSLDAVHs32:
case MVE_VRMLSLDAVHxs32:
return true;
}
return false;
};
LLVMInitializeARMTargetInfo();
LLVMInitializeARMTarget();
LLVMInitializeARMTargetMC();
[ARM] Replace arm vendor with none. NFC
2020-04-22 17:33:11 +02:00
auto TT(Triple::normalize("thumbv8.1m.main-none-none-eabi"));
[ARM][MVE] Add HorizontalReduction flag Add a target flag for instructions that reduce into one, or more, scalar reg(s), including variants of: - VADDV - VABAV - VMINV/VMAXV - VMLADAV Differential Revision: https://reviews.llvm.org/D76683
2020-03-25 12:12:03 +01:00
std::string Error;
const Target *T = TargetRegistry::lookupTarget(TT, Error);
if (!T) {
dbgs() << Error;
return;
}
TargetOptions Options;
auto TM = std::unique_ptr<LLVMTargetMachine>(
static_cast<LLVMTargetMachine*>(
T->createTargetMachine(TT, "generic", "", Options, None, None,
CodeGenOpt::Default)));
ARMSubtarget ST(TM->getTargetTriple(), std::string(TM->getTargetCPU()),
std::string(TM->getTargetFeatureString()),
*static_cast<const ARMBaseTargetMachine *>(TM.get()), false);
const ARMBaseInstrInfo *TII = ST.getInstrInfo();
auto MII = TM->getMCInstrInfo();
for (unsigned i = 0; i < ARM::INSTRUCTION_LIST_END; ++i) {
const MCInstrDesc &Desc = TII->get(i);
uint64_t Flags = Desc.TSFlags;
if ((Flags & ARMII::DomainMask) != ARMII::DomainMVE)
continue;
bool Valid = (Flags & ARMII::HorizontalReduction) != 0;
ASSERT_EQ(HorizontalReduction(i), Valid)
<< MII->getName(i)
<< ": mismatched expectation for tail-predicated safety\n";
}
}
[ARM][MVE] Add target flag for narrowing insts Add a flag, 'RetainsPreviousHalfElement', for operations that operate on top/bottom halves of their input and only write to half of their destination, leaving the other half to retain its previous value. Differential Revision: https://reviews.llvm.org/D76608
2020-03-24 09:23:05 +01:00
TEST(MachineInstructionRetainsPreviousHalfElement, IsCorrect) {
using namespace ARM;
auto RetainsPreviousHalfElement = [](unsigned Opcode) {
switch (Opcode) {
default:
break;
case MVE_VMOVNi16bh:
case MVE_VMOVNi16th:
case MVE_VMOVNi32bh:
case MVE_VMOVNi32th:
case MVE_VQMOVNs16bh:
case MVE_VQMOVNs16th:
case MVE_VQMOVNs32bh:
case MVE_VQMOVNs32th:
case MVE_VQMOVNu16bh:
case MVE_VQMOVNu16th:
case MVE_VQMOVNu32bh:
case MVE_VQMOVNu32th:
case MVE_VQMOVUNs16bh:
case MVE_VQMOVUNs16th:
case MVE_VQMOVUNs32bh:
case MVE_VQMOVUNs32th:
case MVE_VQRSHRNbhs16:
case MVE_VQRSHRNbhs32:
case MVE_VQRSHRNbhu16:
case MVE_VQRSHRNbhu32:
case MVE_VQRSHRNths16:
case MVE_VQRSHRNths32:
case MVE_VQRSHRNthu16:
case MVE_VQRSHRNthu32:
case MVE_VQRSHRUNs16bh:
case MVE_VQRSHRUNs16th:
case MVE_VQRSHRUNs32bh:
case MVE_VQRSHRUNs32th:
case MVE_VQSHRNbhs16:
case MVE_VQSHRNbhs32:
case MVE_VQSHRNbhu16:
case MVE_VQSHRNbhu32:
case MVE_VQSHRNths16:
case MVE_VQSHRNths32:
case MVE_VQSHRNthu16:
case MVE_VQSHRNthu32:
case MVE_VQSHRUNs16bh:
case MVE_VQSHRUNs16th:
case MVE_VQSHRUNs32bh:
case MVE_VQSHRUNs32th:
case MVE_VRSHRNi16bh:
case MVE_VRSHRNi16th:
case MVE_VRSHRNi32bh:
case MVE_VRSHRNi32th:
case MVE_VSHRNi16bh:
case MVE_VSHRNi16th:
case MVE_VSHRNi32bh:
case MVE_VSHRNi32th:
case MVE_VCVTf16f32bh:
case MVE_VCVTf16f32th:
case MVE_VCVTf32f16bh:
case MVE_VCVTf32f16th:
return true;
}
return false;
};
LLVMInitializeARMTargetInfo();
LLVMInitializeARMTarget();
LLVMInitializeARMTargetMC();
[ARM] Replace arm vendor with none. NFC
2020-04-22 17:33:11 +02:00
auto TT(Triple::normalize("thumbv8.1m.main-none-none-eabi"));
[ARM][MVE] Add target flag for narrowing insts Add a flag, 'RetainsPreviousHalfElement', for operations that operate on top/bottom halves of their input and only write to half of their destination, leaving the other half to retain its previous value. Differential Revision: https://reviews.llvm.org/D76608
2020-03-24 09:23:05 +01:00
std::string Error;
const Target *T = TargetRegistry::lookupTarget(TT, Error);
if (!T) {
dbgs() << Error;
return;
}
TargetOptions Options;
auto TM = std::unique_ptr<LLVMTargetMachine>(
static_cast<LLVMTargetMachine*>(
T->createTargetMachine(TT, "generic", "", Options, None, None,
CodeGenOpt::Default)));
ARMSubtarget ST(TM->getTargetTriple(), std::string(TM->getTargetCPU()),
std::string(TM->getTargetFeatureString()),
*static_cast<const ARMBaseTargetMachine *>(TM.get()), false);
const ARMBaseInstrInfo *TII = ST.getInstrInfo();
auto MII = TM->getMCInstrInfo();
for (unsigned i = 0; i < ARM::INSTRUCTION_LIST_END; ++i) {
const MCInstrDesc &Desc = TII->get(i);
uint64_t Flags = Desc.TSFlags;
if ((Flags & ARMII::DomainMask) != ARMII::DomainMVE)
continue;
bool Valid = (Flags & ARMII::RetainsPreviousHalfElement) != 0;
ASSERT_EQ(RetainsPreviousHalfElement(i), Valid)
<< MII->getName(i)
<< ": mismatched expectation for tail-predicated safety\n";
}
}
[ARM][MVE] Add invalidForTailPredication to TSFlags Set this bit for the MVE reduction instructions to prevent a loop from becoming tail predicated in their presence. Differential Revision: https://reviews.llvm.org/D67444 llvm-svn: 372076
2019-09-17 09:43:04 +02:00
// Test for instructions that aren't immediately obviously valid within a
// tail-predicated loop. This should be marked up in their tablegen
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
// descriptions. Currently we, conservatively, disallow:
// - cross beat carries.
// - complex operations.
[ARM][MVE] Tail predicate VML[A|S]LDAV Make the non-exchanging versions of the multiply add/sub instructions validForTailPredication. Differential Revision: https://reviews.llvm.org/D77648
2020-04-09 08:51:33 +02:00
// - horizontal operations with exchange.
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
// - byte swapping.
// - interleaved memory instructions.
// TODO: Add to this list once we can handle them safely.
TEST(MachineInstrValidTailPredication, IsCorrect) {
using namespace ARM;
auto IsValidTPOpcode = [](unsigned Opcode) {
switch (Opcode) {
default:
return false;
case MVE_ASRLi:
case MVE_ASRLr:
[ARM] Allow tail predication of VLDn VLD2/4 instructions cannot be predicated, so we cannot tail predicate them from autovec. From intrinsics though, they should be valid as they will just end up loading extra values into off vector lanes, not effecting the on lanes. The same is true for loads in general where so long as we are not using the other vector lanes, an unpredicated load can be converted to a predicated one. This marks VLD2 and VLD4 instructions as validForTailPredication and allows any unpredicated load in tail predication loop, which seems to be valid given the other checks we have. Differential Revision: https://reviews.llvm.org/D86022
2020-08-18 18:15:45 +02:00
case MVE_LSRL:
[ARM] Add more validForTailPredication Modify the unit test to inspect all MVE instructions and mark the load/store/move of vpr/p0 as valid, as well as the remaining scalar shifts. Differential Revision: https://reviews.llvm.org/D87753
2020-09-16 12:17:13 +02:00
case MVE_LSLLi:
case MVE_LSLLr:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_SQRSHR:
[ARM] Add more validForTailPredication Modify the unit test to inspect all MVE instructions and mark the load/store/move of vpr/p0 as valid, as well as the remaining scalar shifts. Differential Revision: https://reviews.llvm.org/D87753
2020-09-16 12:17:13 +02:00
case MVE_SQRSHRL:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_SQSHL:
[ARM] Add more validForTailPredication Modify the unit test to inspect all MVE instructions and mark the load/store/move of vpr/p0 as valid, as well as the remaining scalar shifts. Differential Revision: https://reviews.llvm.org/D87753
2020-09-16 12:17:13 +02:00
case MVE_SQSHLL:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_SRSHR:
[ARM] Add more validForTailPredication Modify the unit test to inspect all MVE instructions and mark the load/store/move of vpr/p0 as valid, as well as the remaining scalar shifts. Differential Revision: https://reviews.llvm.org/D87753
2020-09-16 12:17:13 +02:00
case MVE_SRSHRL:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_UQRSHL:
[ARM] Add more validForTailPredication Modify the unit test to inspect all MVE instructions and mark the load/store/move of vpr/p0 as valid, as well as the remaining scalar shifts. Differential Revision: https://reviews.llvm.org/D87753
2020-09-16 12:17:13 +02:00
case MVE_UQRSHLL:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_UQSHL:
[ARM] Add more validForTailPredication Modify the unit test to inspect all MVE instructions and mark the load/store/move of vpr/p0 as valid, as well as the remaining scalar shifts. Differential Revision: https://reviews.llvm.org/D87753
2020-09-16 12:17:13 +02:00
case MVE_UQSHLL:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_URSHR:
[ARM] Add more validForTailPredication Modify the unit test to inspect all MVE instructions and mark the load/store/move of vpr/p0 as valid, as well as the remaining scalar shifts. Differential Revision: https://reviews.llvm.org/D87753
2020-09-16 12:17:13 +02:00
case MVE_URSHRL:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VABDf16:
case MVE_VABDf32:
case MVE_VABDs16:
case MVE_VABDs32:
[ARM] Allow tail predication of VLDn VLD2/4 instructions cannot be predicated, so we cannot tail predicate them from autovec. From intrinsics though, they should be valid as they will just end up loading extra values into off vector lanes, not effecting the on lanes. The same is true for loads in general where so long as we are not using the other vector lanes, an unpredicated load can be converted to a predicated one. This marks VLD2 and VLD4 instructions as validForTailPredication and allows any unpredicated load in tail predication loop, which seems to be valid given the other checks we have. Differential Revision: https://reviews.llvm.org/D86022
2020-08-18 18:15:45 +02:00
case MVE_VABDs8:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VABDu16:
case MVE_VABDu32:
case MVE_VABDu8:
case MVE_VABSf16:
case MVE_VABSf32:
case MVE_VABSs16:
case MVE_VABSs32:
case MVE_VABSs8:
case MVE_VADD_qr_f16:
case MVE_VADD_qr_f32:
case MVE_VADD_qr_i16:
case MVE_VADD_qr_i32:
case MVE_VADD_qr_i8:
[ARM][LowOverheadLoops] Add horizontal reduction support Add a bit more logic into the 'FalseLaneZeros' tracking to enable horizontal reductions and also make the VADDV variants validForTailPredication. Differential Revision: https://reviews.llvm.org/D76708
2020-03-30 10:54:25 +02:00
case MVE_VADDVs16acc:
case MVE_VADDVs16no_acc:
case MVE_VADDVs32acc:
case MVE_VADDVs32no_acc:
case MVE_VADDVs8acc:
case MVE_VADDVs8no_acc:
case MVE_VADDVu16acc:
case MVE_VADDVu16no_acc:
case MVE_VADDVu32acc:
case MVE_VADDVu32no_acc:
case MVE_VADDVu8acc:
case MVE_VADDVu8no_acc:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VADDf16:
case MVE_VADDf32:
case MVE_VADDi16:
case MVE_VADDi32:
case MVE_VADDi8:
case MVE_VAND:
case MVE_VBIC:
[ARM,MVE] Revise immediate VBIC/VORR to look more like NEON. Summary: In NEON, the immediate forms of VBIC and VORR are each represented as a single MC instruction, which takes its immediate operand already encoded in a NEON-friendly format: 8 data bits, plus some control bits indicating how to expand them into a full vector. In MVE, we represented immediate VBIC and VORR as four separate MC instructions each, for an 8-bit immediate shifted left by 0, 8, 16 or 24 bits. For each one, the value of the immediate operand is in the 'natural' form, i.e. the numerical value that would actually be BICed or ORRed into each vector lane (and also the same value shown in assembly). For example, MVE_VBICIZ16v4i32 takes an operand such as 0xab0000, which NEON would represent as 0xab | (control bits << 8). The MVE approach is superficially nice (it makes assembly input and output easy, and it's also nice if you're manually constructing immediate VBICs). But it turns out that it's better for isel if we make the NEON and MVE instructions work the same, because the ARMISD::VBICIMM and VORRIMM node types already encode their immediate into the NEON format, so it's easier if we can just use it. Also, this commit reduces the total amount of code rather than increasing it, which is surely an indication that it really is simpler to do it this way! Reviewers: dmgreen, ostannard, miyuki, MarkMurrayARM Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73205
2020-01-23 12:53:27 +01:00
case MVE_VBICimmi16:
case MVE_VBICimmi32:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VBRSR16:
case MVE_VBRSR32:
case MVE_VBRSR8:
case MVE_VCLSs16:
case MVE_VCLSs32:
case MVE_VCLSs8:
case MVE_VCLZs16:
case MVE_VCLZs32:
case MVE_VCLZs8:
case MVE_VCMPf16:
case MVE_VCMPf16r:
case MVE_VCMPf32:
case MVE_VCMPf32r:
case MVE_VCMPi16:
case MVE_VCMPi16r:
case MVE_VCMPi32:
case MVE_VCMPi32r:
case MVE_VCMPi8:
case MVE_VCMPi8r:
case MVE_VCMPs16:
case MVE_VCMPs16r:
case MVE_VCMPs32:
case MVE_VCMPs32r:
case MVE_VCMPs8:
case MVE_VCMPs8r:
case MVE_VCMPu16:
case MVE_VCMPu16r:
case MVE_VCMPu32:
case MVE_VCMPu32r:
case MVE_VCMPu8:
case MVE_VCMPu8r:
case MVE_VCTP16:
case MVE_VCTP32:
case MVE_VCTP64:
case MVE_VCTP8:
case MVE_VCVTf16s16_fix:
case MVE_VCVTf16s16n:
case MVE_VCVTf16u16_fix:
case MVE_VCVTf16u16n:
case MVE_VCVTf32s32_fix:
case MVE_VCVTf32s32n:
case MVE_VCVTf32u32_fix:
case MVE_VCVTf32u32n:
case MVE_VCVTs16f16_fix:
case MVE_VCVTs16f16a:
case MVE_VCVTs16f16m:
case MVE_VCVTs16f16n:
case MVE_VCVTs16f16p:
case MVE_VCVTs16f16z:
case MVE_VCVTs32f32_fix:
case MVE_VCVTs32f32a:
case MVE_VCVTs32f32m:
case MVE_VCVTs32f32n:
case MVE_VCVTs32f32p:
case MVE_VCVTs32f32z:
case MVE_VCVTu16f16_fix:
case MVE_VCVTu16f16a:
case MVE_VCVTu16f16m:
case MVE_VCVTu16f16n:
case MVE_VCVTu16f16p:
case MVE_VCVTu16f16z:
case MVE_VCVTu32f32_fix:
case MVE_VCVTu32f32a:
case MVE_VCVTu32f32m:
case MVE_VCVTu32f32n:
case MVE_VCVTu32f32p:
case MVE_VCVTu32f32z:
case MVE_VDDUPu16:
case MVE_VDDUPu32:
case MVE_VDDUPu8:
case MVE_VDUP16:
case MVE_VDUP32:
case MVE_VDUP8:
case MVE_VDWDUPu16:
case MVE_VDWDUPu32:
case MVE_VDWDUPu8:
case MVE_VEOR:
case MVE_VFMA_qr_Sf16:
case MVE_VFMA_qr_Sf32:
case MVE_VFMA_qr_f16:
case MVE_VFMA_qr_f32:
[ARM][MVE] VFMA and VFMS validForTailPredication Add four instructions to the whitelist. Differential Revision: https://reviews.llvm.org/D75902
2020-03-10 11:38:25 +01:00
case MVE_VFMAf16:
case MVE_VFMAf32:
case MVE_VFMSf16:
case MVE_VFMSf32:
[ARM][MVE] Tail predicate VMAX,VMAXA,VMIN,VMINA Add the MVE min and max instructions to our tail predication whitelist. Differential Revision: https://reviews.llvm.org/D72502
2020-01-10 14:08:30 +01:00
case MVE_VMAXAs16:
case MVE_VMAXAs32:
case MVE_VMAXAs8:
case MVE_VMAXs16:
case MVE_VMAXs32:
case MVE_VMAXs8:
case MVE_VMAXu16:
case MVE_VMAXu32:
case MVE_VMAXu8:
case MVE_VMINAs16:
case MVE_VMINAs32:
case MVE_VMINAs8:
case MVE_VMINs16:
case MVE_VMINs32:
case MVE_VMINs8:
case MVE_VMINu16:
case MVE_VMINu32:
case MVE_VMINu8:
[ARM][MVE] Tail predicate VML[A|S]LDAV Make the non-exchanging versions of the multiply add/sub instructions validForTailPredication. Differential Revision: https://reviews.llvm.org/D77648
2020-04-09 08:51:33 +02:00
case MVE_VMLADAVas16:
case MVE_VMLADAVas32:
case MVE_VMLADAVas8:
case MVE_VMLADAVau16:
case MVE_VMLADAVau32:
case MVE_VMLADAVau8:
case MVE_VMLADAVs16:
case MVE_VMLADAVs32:
case MVE_VMLADAVs8:
case MVE_VMLADAVu16:
case MVE_VMLADAVu32:
case MVE_VMLADAVu8:
case MVE_VMLALDAVs16:
case MVE_VMLALDAVs32:
case MVE_VMLALDAVu16:
case MVE_VMLALDAVu32:
case MVE_VMLALDAVas16:
case MVE_VMLALDAVas32:
case MVE_VMLALDAVau16:
case MVE_VMLALDAVau32:
case MVE_VMLSDAVas16:
case MVE_VMLSDAVas32:
case MVE_VMLSDAVas8:
case MVE_VMLSDAVs16:
case MVE_VMLSDAVs32:
case MVE_VMLSDAVs8:
case MVE_VMLSLDAVas16:
case MVE_VMLSLDAVas32:
case MVE_VMLSLDAVs16:
case MVE_VMLSLDAVs32:
case MVE_VRMLALDAVHas32:
case MVE_VRMLALDAVHau32:
case MVE_VRMLALDAVHs32:
case MVE_VRMLALDAVHu32:
case MVE_VRMLSLDAVHas32:
case MVE_VRMLSLDAVHs32:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VMLAS_qr_s16:
case MVE_VMLAS_qr_s32:
case MVE_VMLAS_qr_s8:
case MVE_VMLAS_qr_u16:
case MVE_VMLAS_qr_u32:
case MVE_VMLAS_qr_u8:
case MVE_VMLA_qr_s16:
case MVE_VMLA_qr_s32:
case MVE_VMLA_qr_s8:
case MVE_VMLA_qr_u16:
case MVE_VMLA_qr_u32:
case MVE_VMLA_qr_u8:
case MVE_VHADD_qr_s16:
case MVE_VHADD_qr_s32:
case MVE_VHADD_qr_s8:
case MVE_VHADD_qr_u16:
case MVE_VHADD_qr_u32:
case MVE_VHADD_qr_u8:
case MVE_VHADDs16:
case MVE_VHADDs32:
case MVE_VHADDs8:
case MVE_VHADDu16:
case MVE_VHADDu32:
case MVE_VHADDu8:
case MVE_VHSUB_qr_s16:
case MVE_VHSUB_qr_s32:
case MVE_VHSUB_qr_s8:
case MVE_VHSUB_qr_u16:
case MVE_VHSUB_qr_u32:
case MVE_VHSUB_qr_u8:
case MVE_VHSUBs16:
case MVE_VHSUBs32:
case MVE_VHSUBs8:
case MVE_VHSUBu16:
case MVE_VHSUBu32:
case MVE_VHSUBu8:
case MVE_VIDUPu16:
case MVE_VIDUPu32:
case MVE_VIDUPu8:
case MVE_VIWDUPu16:
case MVE_VIWDUPu32:
case MVE_VIWDUPu8:
[ARM] Allow tail predication of VLDn VLD2/4 instructions cannot be predicated, so we cannot tail predicate them from autovec. From intrinsics though, they should be valid as they will just end up loading extra values into off vector lanes, not effecting the on lanes. The same is true for loads in general where so long as we are not using the other vector lanes, an unpredicated load can be converted to a predicated one. This marks VLD2 and VLD4 instructions as validForTailPredication and allows any unpredicated load in tail predication loop, which seems to be valid given the other checks we have. Differential Revision: https://reviews.llvm.org/D86022
2020-08-18 18:15:45 +02:00
case MVE_VLD20_8:
case MVE_VLD21_8:
case MVE_VLD20_16:
case MVE_VLD21_16:
case MVE_VLD20_32:
case MVE_VLD21_32:
case MVE_VLD20_8_wb:
case MVE_VLD21_8_wb:
case MVE_VLD20_16_wb:
case MVE_VLD21_16_wb:
case MVE_VLD20_32_wb:
case MVE_VLD21_32_wb:
case MVE_VLD40_8:
case MVE_VLD41_8:
case MVE_VLD42_8:
case MVE_VLD43_8:
case MVE_VLD40_16:
case MVE_VLD41_16:
case MVE_VLD42_16:
case MVE_VLD43_16:
case MVE_VLD40_32:
case MVE_VLD41_32:
case MVE_VLD42_32:
case MVE_VLD43_32:
case MVE_VLD40_8_wb:
case MVE_VLD41_8_wb:
case MVE_VLD42_8_wb:
case MVE_VLD43_8_wb:
case MVE_VLD40_16_wb:
case MVE_VLD41_16_wb:
case MVE_VLD42_16_wb:
case MVE_VLD43_16_wb:
case MVE_VLD40_32_wb:
case MVE_VLD41_32_wb:
case MVE_VLD42_32_wb:
case MVE_VLD43_32_wb:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VLDRBS16:
case MVE_VLDRBS16_post:
case MVE_VLDRBS16_pre:
case MVE_VLDRBS16_rq:
case MVE_VLDRBS32:
case MVE_VLDRBS32_post:
case MVE_VLDRBS32_pre:
case MVE_VLDRBS32_rq:
case MVE_VLDRBU16:
case MVE_VLDRBU16_post:
case MVE_VLDRBU16_pre:
case MVE_VLDRBU16_rq:
case MVE_VLDRBU32:
case MVE_VLDRBU32_post:
case MVE_VLDRBU32_pre:
case MVE_VLDRBU32_rq:
case MVE_VLDRBU8:
case MVE_VLDRBU8_post:
case MVE_VLDRBU8_pre:
case MVE_VLDRBU8_rq:
case MVE_VLDRDU64_qi:
case MVE_VLDRDU64_qi_pre:
case MVE_VLDRDU64_rq:
case MVE_VLDRDU64_rq_u:
case MVE_VLDRHS32:
case MVE_VLDRHS32_post:
case MVE_VLDRHS32_pre:
case MVE_VLDRHS32_rq:
case MVE_VLDRHS32_rq_u:
case MVE_VLDRHU16:
case MVE_VLDRHU16_post:
case MVE_VLDRHU16_pre:
case MVE_VLDRHU16_rq:
case MVE_VLDRHU16_rq_u:
case MVE_VLDRHU32:
case MVE_VLDRHU32_post:
case MVE_VLDRHU32_pre:
case MVE_VLDRHU32_rq:
case MVE_VLDRHU32_rq_u:
case MVE_VLDRWU32:
case MVE_VLDRWU32_post:
case MVE_VLDRWU32_pre:
case MVE_VLDRWU32_qi:
case MVE_VLDRWU32_qi_pre:
case MVE_VLDRWU32_rq:
case MVE_VLDRWU32_rq_u:
case MVE_VMOVimmf32:
case MVE_VMOVimmi16:
[ARM] Allow tail predication of VLDn VLD2/4 instructions cannot be predicated, so we cannot tail predicate them from autovec. From intrinsics though, they should be valid as they will just end up loading extra values into off vector lanes, not effecting the on lanes. The same is true for loads in general where so long as we are not using the other vector lanes, an unpredicated load can be converted to a predicated one. This marks VLD2 and VLD4 instructions as validForTailPredication and allows any unpredicated load in tail predication loop, which seems to be valid given the other checks we have. Differential Revision: https://reviews.llvm.org/D86022
2020-08-18 18:15:45 +02:00
case MVE_VMOVimmi32:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VMOVimmi64:
[ARM] Allow tail predication of VLDn VLD2/4 instructions cannot be predicated, so we cannot tail predicate them from autovec. From intrinsics though, they should be valid as they will just end up loading extra values into off vector lanes, not effecting the on lanes. The same is true for loads in general where so long as we are not using the other vector lanes, an unpredicated load can be converted to a predicated one. This marks VLD2 and VLD4 instructions as validForTailPredication and allows any unpredicated load in tail predication loop, which seems to be valid given the other checks we have. Differential Revision: https://reviews.llvm.org/D86022
2020-08-18 18:15:45 +02:00
case MVE_VMOVimmi8:
[ARM][MVE] Enable VMOVN for tail predication These instructions also don't exchange lanes, so make them legal. Differential Revision: https://reviews.llvm.org/D75669
2020-03-05 12:30:37 +01:00
case MVE_VMOVNi16bh:
case MVE_VMOVNi16th:
case MVE_VMOVNi32bh:
case MVE_VMOVNi32th:
[ARM][MVE] Tail predicate bottom/top muls. Add VMULL and VQDMULL variants to our tail predication white list. Differential Revision: https://reviews.llvm.org/D71465
2019-12-13 15:41:08 +01:00
case MVE_VMULLBp16:
case MVE_VMULLBp8:
case MVE_VMULLBs16:
case MVE_VMULLBs32:
case MVE_VMULLBs8:
case MVE_VMULLBu16:
case MVE_VMULLBu32:
case MVE_VMULLBu8:
case MVE_VMULLTp16:
case MVE_VMULLTp8:
case MVE_VMULLTs16:
case MVE_VMULLTs32:
case MVE_VMULLTs8:
case MVE_VMULLTu16:
case MVE_VMULLTu32:
[ARM] Allow tail predication of VLDn VLD2/4 instructions cannot be predicated, so we cannot tail predicate them from autovec. From intrinsics though, they should be valid as they will just end up loading extra values into off vector lanes, not effecting the on lanes. The same is true for loads in general where so long as we are not using the other vector lanes, an unpredicated load can be converted to a predicated one. This marks VLD2 and VLD4 instructions as validForTailPredication and allows any unpredicated load in tail predication loop, which seems to be valid given the other checks we have. Differential Revision: https://reviews.llvm.org/D86022
2020-08-18 18:15:45 +02:00
case MVE_VMULLTu8:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VMUL_qr_f16:
case MVE_VMUL_qr_f32:
case MVE_VMUL_qr_i16:
case MVE_VMUL_qr_i32:
case MVE_VMUL_qr_i8:
case MVE_VMULf16:
case MVE_VMULf32:
[ARM][MVE][Intrinsics] Add MVE VMUL intrinsics. Remove annoying "t1" from VMUL* instructions. Add unit tests. Summary: Add MVE VMUL intrinsics. Remove annoying "t1" from VMUL* instructions. Add unit tests. Reviewers: simon_tatham, ostannard, dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D70546
2019-11-25 15:10:59 +01:00
case MVE_VMULi16:
case MVE_VMULi8:
case MVE_VMULi32:
[ARM] Add patterns for vmulh Now that vmulh can be selected, this adds the MVE patterns to make it legal and generate instructions. Differential Revision: https://reviews.llvm.org/D88011
2021-05-26 10:22:12 +02:00
case MVE_VMULHs32:
case MVE_VMULHs16:
case MVE_VMULHs8:
case MVE_VMULHu32:
case MVE_VMULHu16:
case MVE_VMULHu8:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VMVN:
case MVE_VMVNimmi16:
case MVE_VMVNimmi32:
case MVE_VNEGf16:
case MVE_VNEGf32:
case MVE_VNEGs16:
case MVE_VNEGs32:
case MVE_VNEGs8:
case MVE_VORN:
case MVE_VORR:
[ARM,MVE] Revise immediate VBIC/VORR to look more like NEON. Summary: In NEON, the immediate forms of VBIC and VORR are each represented as a single MC instruction, which takes its immediate operand already encoded in a NEON-friendly format: 8 data bits, plus some control bits indicating how to expand them into a full vector. In MVE, we represented immediate VBIC and VORR as four separate MC instructions each, for an 8-bit immediate shifted left by 0, 8, 16 or 24 bits. For each one, the value of the immediate operand is in the 'natural' form, i.e. the numerical value that would actually be BICed or ORRed into each vector lane (and also the same value shown in assembly). For example, MVE_VBICIZ16v4i32 takes an operand such as 0xab0000, which NEON would represent as 0xab | (control bits << 8). The MVE approach is superficially nice (it makes assembly input and output easy, and it's also nice if you're manually constructing immediate VBICs). But it turns out that it's better for isel if we make the NEON and MVE instructions work the same, because the ARMISD::VBICIMM and VORRIMM node types already encode their immediate into the NEON format, so it's easier if we can just use it. Also, this commit reduces the total amount of code rather than increasing it, which is surely an indication that it really is simpler to do it this way! Reviewers: dmgreen, ostannard, miyuki, MarkMurrayARM Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73205
2020-01-23 12:53:27 +01:00
case MVE_VORRimmi16:
case MVE_VORRimmi32:
[ARM] Allow tail predication of VLDn VLD2/4 instructions cannot be predicated, so we cannot tail predicate them from autovec. From intrinsics though, they should be valid as they will just end up loading extra values into off vector lanes, not effecting the on lanes. The same is true for loads in general where so long as we are not using the other vector lanes, an unpredicated load can be converted to a predicated one. This marks VLD2 and VLD4 instructions as validForTailPredication and allows any unpredicated load in tail predication loop, which seems to be valid given the other checks we have. Differential Revision: https://reviews.llvm.org/D86022
2020-08-18 18:15:45 +02:00
case MVE_VPST:
[ARM] VPT validForTailPredication Mark all VPT instructions as valid. Differential Revision: https://reviews.llvm.org/D87759
2020-09-16 15:30:47 +02:00
case MVE_VPTv16i8:
case MVE_VPTv8i16:
case MVE_VPTv4i32:
case MVE_VPTv16i8r:
case MVE_VPTv8i16r:
case MVE_VPTv4i32r:
case MVE_VPTv16s8:
case MVE_VPTv8s16:
case MVE_VPTv4s32:
case MVE_VPTv16s8r:
case MVE_VPTv8s16r:
case MVE_VPTv4s32r:
case MVE_VPTv16u8:
case MVE_VPTv8u16:
case MVE_VPTv4u32:
case MVE_VPTv16u8r:
case MVE_VPTv8u16r:
case MVE_VPTv4u32r:
case MVE_VPTv8f16:
case MVE_VPTv4f32:
case MVE_VPTv8f16r:
case MVE_VPTv4f32r:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VQABSs16:
case MVE_VQABSs32:
case MVE_VQABSs8:
case MVE_VQADD_qr_s16:
case MVE_VQADD_qr_s32:
case MVE_VQADD_qr_s8:
case MVE_VQADD_qr_u16:
case MVE_VQADD_qr_u32:
case MVE_VQADD_qr_u8:
case MVE_VQADDs16:
case MVE_VQADDs32:
case MVE_VQADDs8:
case MVE_VQADDu16:
case MVE_VQADDu32:
case MVE_VQADDu8:
[ARM] Tail predicate VQDMULH and VQRDMULH Mark the family of instructions as valid for tail predication. Differential Revision: https://reviews.llvm.org/D87348
2020-09-09 09:15:55 +02:00
case MVE_VQDMULH_qr_s16:
case MVE_VQDMULH_qr_s32:
case MVE_VQDMULH_qr_s8:
case MVE_VQDMULHi16:
case MVE_VQDMULHi32:
case MVE_VQDMULHi8:
[ARM][MVE] Tail predicate bottom/top muls. Add VMULL and VQDMULL variants to our tail predication white list. Differential Revision: https://reviews.llvm.org/D71465
2019-12-13 15:41:08 +01:00
case MVE_VQDMULL_qr_s16bh:
case MVE_VQDMULL_qr_s16th:
case MVE_VQDMULL_qr_s32bh:
case MVE_VQDMULL_qr_s32th:
case MVE_VQDMULLs16bh:
case MVE_VQDMULLs16th:
case MVE_VQDMULLs32bh:
case MVE_VQDMULLs32th:
[ARM] Tail predicate VQDMULH and VQRDMULH Mark the family of instructions as valid for tail predication. Differential Revision: https://reviews.llvm.org/D87348
2020-09-09 09:15:55 +02:00
case MVE_VQRDMULH_qr_s16:
case MVE_VQRDMULH_qr_s32:
case MVE_VQRDMULH_qr_s8:
case MVE_VQRDMULHi16:
case MVE_VQRDMULHi32:
case MVE_VQRDMULHi8:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VQNEGs16:
case MVE_VQNEGs32:
case MVE_VQNEGs8:
[ARM][MVE] Enable VMOVN for tail predication These instructions also don't exchange lanes, so make them legal. Differential Revision: https://reviews.llvm.org/D75669
2020-03-05 12:30:37 +01:00
case MVE_VQMOVNs16bh:
case MVE_VQMOVNs16th:
case MVE_VQMOVNs32bh:
case MVE_VQMOVNs32th:
case MVE_VQMOVNu16bh:
case MVE_VQMOVNu16th:
case MVE_VQMOVNu32bh:
case MVE_VQMOVNu32th:
case MVE_VQMOVUNs16bh:
case MVE_VQMOVUNs16th:
case MVE_VQMOVUNs32bh:
case MVE_VQMOVUNs32th:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VQRSHL_by_vecs16:
case MVE_VQRSHL_by_vecs32:
case MVE_VQRSHL_by_vecs8:
case MVE_VQRSHL_by_vecu16:
case MVE_VQRSHL_by_vecu32:
case MVE_VQRSHL_by_vecu8:
case MVE_VQRSHL_qrs16:
case MVE_VQRSHL_qrs32:
case MVE_VQRSHL_qrs8:
case MVE_VQRSHL_qru16:
case MVE_VQRSHL_qru8:
case MVE_VQRSHL_qru32:
case MVE_VQSHLU_imms16:
case MVE_VQSHLU_imms32:
case MVE_VQSHLU_imms8:
[ARM][MVE] Fix copy-paste error in VQSHL instruction ids. Summary: The immediate forms of the MVE VQSHL instruction have MC names like `MVE_VSLIimms8` and `MVE_VSLIimmu32`. Those names are confusing, because VSLI is a completely different shift instruction with no semantic relation to VQSHL. But it just happens to be defined immediately before VQSHL in `ARMInstrMVE.td`, so this looks like a copy-paste error. Renamed the ids to match the instruction name. Reviewers: ostannard, dmgreen, MarkMurrayARM, miyuki Reviewed By: miyuki Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71114
2019-12-06 16:23:07 +01:00
case MVE_VQSHLimms16:
case MVE_VQSHLimms32:
case MVE_VQSHLimms8:
case MVE_VQSHLimmu16:
case MVE_VQSHLimmu32:
case MVE_VQSHLimmu8:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VQSHL_by_vecs16:
case MVE_VQSHL_by_vecs32:
case MVE_VQSHL_by_vecs8:
case MVE_VQSHL_by_vecu16:
case MVE_VQSHL_by_vecu32:
case MVE_VQSHL_by_vecu8:
case MVE_VQSHL_qrs16:
case MVE_VQSHL_qrs32:
case MVE_VQSHL_qrs8:
case MVE_VQSHL_qru16:
case MVE_VQSHL_qru32:
case MVE_VQSHL_qru8:
[ARM][MVE] Enable *SHRN* for tail predication These instructions don't swap lanes so make them valid. Differential Revision: https://reviews.llvm.org/D75667
2020-03-05 10:54:11 +01:00
case MVE_VQRSHRNbhs16:
case MVE_VQRSHRNbhs32:
case MVE_VQRSHRNbhu16:
case MVE_VQRSHRNbhu32:
case MVE_VQRSHRNths16:
case MVE_VQRSHRNths32:
case MVE_VQRSHRNthu16:
case MVE_VQRSHRNthu32:
case MVE_VQRSHRUNs16bh:
case MVE_VQRSHRUNs16th:
case MVE_VQRSHRUNs32bh:
case MVE_VQRSHRUNs32th:
case MVE_VQSHRNbhs16:
case MVE_VQSHRNbhs32:
case MVE_VQSHRNbhu16:
case MVE_VQSHRNbhu32:
case MVE_VQSHRNths16:
case MVE_VQSHRNths32:
case MVE_VQSHRNthu16:
case MVE_VQSHRNthu32:
case MVE_VQSHRUNs16bh:
case MVE_VQSHRUNs16th:
case MVE_VQSHRUNs32bh:
case MVE_VQSHRUNs32th:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VQSUB_qr_s16:
case MVE_VQSUB_qr_s32:
case MVE_VQSUB_qr_s8:
case MVE_VQSUB_qr_u16:
case MVE_VQSUB_qr_u32:
case MVE_VQSUB_qr_u8:
case MVE_VQSUBs16:
case MVE_VQSUBs32:
case MVE_VQSUBs8:
case MVE_VQSUBu16:
case MVE_VQSUBu32:
case MVE_VQSUBu8:
case MVE_VRHADDs16:
case MVE_VRHADDs32:
case MVE_VRHADDs8:
case MVE_VRHADDu16:
[ARM] Allow tail predication of VLDn VLD2/4 instructions cannot be predicated, so we cannot tail predicate them from autovec. From intrinsics though, they should be valid as they will just end up loading extra values into off vector lanes, not effecting the on lanes. The same is true for loads in general where so long as we are not using the other vector lanes, an unpredicated load can be converted to a predicated one. This marks VLD2 and VLD4 instructions as validForTailPredication and allows any unpredicated load in tail predication loop, which seems to be valid given the other checks we have. Differential Revision: https://reviews.llvm.org/D86022
2020-08-18 18:15:45 +02:00
case MVE_VRHADDu32:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VRHADDu8:
case MVE_VRINTf16A:
case MVE_VRINTf16M:
case MVE_VRINTf16N:
case MVE_VRINTf16P:
case MVE_VRINTf16X:
case MVE_VRINTf16Z:
case MVE_VRINTf32A:
case MVE_VRINTf32M:
case MVE_VRINTf32N:
[ARM] Allow tail predication of VLDn VLD2/4 instructions cannot be predicated, so we cannot tail predicate them from autovec. From intrinsics though, they should be valid as they will just end up loading extra values into off vector lanes, not effecting the on lanes. The same is true for loads in general where so long as we are not using the other vector lanes, an unpredicated load can be converted to a predicated one. This marks VLD2 and VLD4 instructions as validForTailPredication and allows any unpredicated load in tail predication loop, which seems to be valid given the other checks we have. Differential Revision: https://reviews.llvm.org/D86022
2020-08-18 18:15:45 +02:00
case MVE_VRINTf32P:
case MVE_VRINTf32X:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VRINTf32Z:
[ARM] Add patterns for vmulh Now that vmulh can be selected, this adds the MVE patterns to make it legal and generate instructions. Differential Revision: https://reviews.llvm.org/D88011
2021-05-26 10:22:12 +02:00
case MVE_VRMULHs32:
case MVE_VRMULHs16:
case MVE_VRMULHs8:
case MVE_VRMULHu32:
case MVE_VRMULHu16:
case MVE_VRMULHu8:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VRSHL_by_vecs16:
case MVE_VRSHL_by_vecs32:
[ARM] Allow tail predication of VLDn VLD2/4 instructions cannot be predicated, so we cannot tail predicate them from autovec. From intrinsics though, they should be valid as they will just end up loading extra values into off vector lanes, not effecting the on lanes. The same is true for loads in general where so long as we are not using the other vector lanes, an unpredicated load can be converted to a predicated one. This marks VLD2 and VLD4 instructions as validForTailPredication and allows any unpredicated load in tail predication loop, which seems to be valid given the other checks we have. Differential Revision: https://reviews.llvm.org/D86022
2020-08-18 18:15:45 +02:00
case MVE_VRSHL_by_vecs8:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VRSHL_by_vecu16:
case MVE_VRSHL_by_vecu32:
case MVE_VRSHL_by_vecu8:
case MVE_VRSHL_qrs16:
case MVE_VRSHL_qrs32:
case MVE_VRSHL_qrs8:
case MVE_VRSHL_qru16:
case MVE_VRSHL_qru32:
case MVE_VRSHL_qru8:
case MVE_VRSHR_imms16:
case MVE_VRSHR_imms32:
case MVE_VRSHR_imms8:
case MVE_VRSHR_immu16:
case MVE_VRSHR_immu32:
case MVE_VRSHR_immu8:
[ARM][MVE] Enable *SHRN* for tail predication These instructions don't swap lanes so make them valid. Differential Revision: https://reviews.llvm.org/D75667
2020-03-05 10:54:11 +01:00
case MVE_VRSHRNi16bh:
case MVE_VRSHRNi16th:
case MVE_VRSHRNi32bh:
case MVE_VRSHRNi32th:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VSHL_by_vecs16:
case MVE_VSHL_by_vecs32:
case MVE_VSHL_by_vecs8:
case MVE_VSHL_by_vecu16:
case MVE_VSHL_by_vecu32:
case MVE_VSHL_by_vecu8:
case MVE_VSHL_immi16:
case MVE_VSHL_immi32:
case MVE_VSHL_immi8:
case MVE_VSHL_qrs16:
case MVE_VSHL_qrs32:
case MVE_VSHL_qrs8:
case MVE_VSHL_qru16:
case MVE_VSHL_qru32:
case MVE_VSHL_qru8:
case MVE_VSHR_imms16:
case MVE_VSHR_imms32:
case MVE_VSHR_imms8:
case MVE_VSHR_immu16:
case MVE_VSHR_immu32:
case MVE_VSHR_immu8:
[ARM][MVE] Enable *SHRN* for tail predication These instructions don't swap lanes so make them valid. Differential Revision: https://reviews.llvm.org/D75667
2020-03-05 10:54:11 +01:00
case MVE_VSHRNi16bh:
case MVE_VSHRNi16th:
case MVE_VSHRNi32bh:
case MVE_VSHRNi32th:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VSLIimm16:
case MVE_VSLIimm32:
case MVE_VSLIimm8:
case MVE_VSRIimm16:
case MVE_VSRIimm32:
case MVE_VSRIimm8:
case MVE_VSTRB16:
case MVE_VSTRB16_post:
case MVE_VSTRB16_pre:
case MVE_VSTRB16_rq:
case MVE_VSTRB32:
case MVE_VSTRB32_post:
[ARM] Allow tail predication of VLDn VLD2/4 instructions cannot be predicated, so we cannot tail predicate them from autovec. From intrinsics though, they should be valid as they will just end up loading extra values into off vector lanes, not effecting the on lanes. The same is true for loads in general where so long as we are not using the other vector lanes, an unpredicated load can be converted to a predicated one. This marks VLD2 and VLD4 instructions as validForTailPredication and allows any unpredicated load in tail predication loop, which seems to be valid given the other checks we have. Differential Revision: https://reviews.llvm.org/D86022
2020-08-18 18:15:45 +02:00
case MVE_VSTRB32_pre:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
case MVE_VSTRB32_rq:
case MVE_VSTRB8_rq:
case MVE_VSTRBU8:
case MVE_VSTRBU8_post:
case MVE_VSTRBU8_pre:
case MVE_VSTRD64_qi:
case MVE_VSTRD64_qi_pre:
case MVE_VSTRD64_rq:
case MVE_VSTRD64_rq_u:
case MVE_VSTRH16_rq:
case MVE_VSTRH16_rq_u:
case MVE_VSTRH32:
case MVE_VSTRH32_post:
case MVE_VSTRH32_pre:
case MVE_VSTRH32_rq:
case MVE_VSTRH32_rq_u:
case MVE_VSTRHU16:
case MVE_VSTRHU16_post:
case MVE_VSTRHU16_pre:
case MVE_VSTRW32_qi:
case MVE_VSTRW32_qi_pre:
case MVE_VSTRW32_rq:
case MVE_VSTRW32_rq_u:
case MVE_VSTRWU32:
case MVE_VSTRWU32_post:
case MVE_VSTRWU32_pre:
case MVE_VSUB_qr_f16:
case MVE_VSUB_qr_f32:
case MVE_VSUB_qr_i16:
case MVE_VSUB_qr_i32:
case MVE_VSUB_qr_i8:
case MVE_VSUBf16:
case MVE_VSUBf32:
case MVE_VSUBi16:
case MVE_VSUBi32:
case MVE_VSUBi8:
[ARM] Add more validForTailPredication Modify the unit test to inspect all MVE instructions and mark the load/store/move of vpr/p0 as valid, as well as the remaining scalar shifts. Differential Revision: https://reviews.llvm.org/D87753
2020-09-16 12:17:13 +02:00
case VLDR_P0_off:
case VLDR_P0_post:
case VLDR_P0_pre:
case VLDR_VPR_off:
case VLDR_VPR_post:
case VLDR_VPR_pre:
case VSTR_P0_off:
case VSTR_P0_post:
case VSTR_P0_pre:
case VSTR_VPR_off:
case VSTR_VPR_post:
case VSTR_VPR_pre:
case VMRS_P0:
case VMRS_VPR:
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
return true;
}
};
[ARM][MVE] Add invalidForTailPredication to TSFlags Set this bit for the MVE reduction instructions to prevent a loop from becoming tail predicated in their presence. Differential Revision: https://reviews.llvm.org/D67444 llvm-svn: 372076
2019-09-17 09:43:04 +02:00
LLVMInitializeARMTargetInfo();
LLVMInitializeARMTarget();
LLVMInitializeARMTargetMC();
[ARM] Replace arm vendor with none. NFC
2020-04-22 17:33:11 +02:00
auto TT(Triple::normalize("thumbv8.1m.main-none-none-eabi"));
[ARM][MVE] Add invalidForTailPredication to TSFlags Set this bit for the MVE reduction instructions to prevent a loop from becoming tail predicated in their presence. Differential Revision: https://reviews.llvm.org/D67444 llvm-svn: 372076
2019-09-17 09:43:04 +02:00
std::string Error;
const Target *T = TargetRegistry::lookupTarget(TT, Error);
if (!T) {
dbgs() << Error;
return;
}
TargetOptions Options;
auto TM = std::unique_ptr<LLVMTargetMachine>(
static_cast<LLVMTargetMachine*>(
T->createTargetMachine(TT, "generic", "", Options, None, None,
CodeGenOpt::Default)));
Make llvm::StringRef to std::string conversions explicit. This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-28 20:23:46 +01:00
ARMSubtarget ST(TM->getTargetTriple(), std::string(TM->getTargetCPU()),
std::string(TM->getTargetFeatureString()),
*static_cast<const ARMBaseTargetMachine *>(TM.get()), false);
[ARM][MVE] Add invalidForTailPredication to TSFlags Set this bit for the MVE reduction instructions to prevent a loop from becoming tail predicated in their presence. Differential Revision: https://reviews.llvm.org/D67444 llvm-svn: 372076
2019-09-17 09:43:04 +02:00
[ARM] Add more validForTailPredication Modify the unit test to inspect all MVE instructions and mark the load/store/move of vpr/p0 as valid, as well as the remaining scalar shifts. Differential Revision: https://reviews.llvm.org/D87753
2020-09-16 12:17:13 +02:00
auto MII = TM->getMCInstrInfo();
[ARM][MVE] validForTailPredication insts Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
2019-10-15 15:12:51 +02:00
for (unsigned i = 0; i < ARM::INSTRUCTION_LIST_END; ++i) {
[ARM] Add more validForTailPredication Modify the unit test to inspect all MVE instructions and mark the load/store/move of vpr/p0 as valid, as well as the remaining scalar shifts. Differential Revision: https://reviews.llvm.org/D87753
2020-09-16 12:17:13 +02:00
uint64_t Flags = MII->get(i).TSFlags;
if ((Flags & ARMII::DomainMask) != ARMII::DomainMVE)
continue;
bool Valid = (Flags & ARMII::ValidForTailPredication) != 0;
ASSERT_EQ(IsValidTPOpcode(i), Valid)
<< MII->getName(i)
<< ": mismatched expectation for tail-predicated safety\n";
[ARM][MVE] Add invalidForTailPredication to TSFlags Set this bit for the MVE reduction instructions to prevent a loop from becoming tail predicated in their presence. Differential Revision: https://reviews.llvm.org/D67444 llvm-svn: 372076
2019-09-17 09:43:04 +02:00
}
}
[ARM] Mark MVE loads/store as not having side effects The hasSideEffect parameter is usually automatically inferred from instruction patterns. For some of our MVE instructions, we do not have patterns though, such as for the pre/post inc loads and stores. This instead specifies the flag manually on the base MVE_VLDRSTR_base tablegen class, making sure we get this correct. This can help with scheduling multiple loads more optimally. Here I've added a unittest as a more direct form of testing. Differential Revision: https://reviews.llvm.org/D73117
2020-01-22 16:59:33 +01:00
TEST(MachineInstr, HasSideEffects) {
using namespace ARM;
[ARM] Make remaining MVE instruction predictable The unpredictable/hasSideEffects flag is usually inferred by tablegen from whether the instruction has a tablegen pattern (and that pattern only has a single output instruction). Now that the MVE intrinsics are all committed and producing code, the remaining instructions still marked as unpredictable need to be specially handled. This adds the flag directly to instructions that need it, notably the V*MLAL instructions and some of the MOV's. Differential Revision: https://reviews.llvm.org/D76910
2020-03-28 16:32:47 +01:00
std::set<unsigned> UnpredictableOpcodes = {
[ARM] Remove hasSideEffects from FP converts Whether an instruction is deemed to have side effects in determined by whether it has a tblgen pattern that emits a single instruction. Because of the way a lot of the the vcvt instructions are specified either in dagtodag code or with patterns that emit multiple instructions, they don't get marked as not having side effects. This just marks them as not having side effects manually. It can help especially with instruction scheduling, to not create artificial barriers, but one of these tests also managed to produce fewer instructions. Differential Revision: https://reviews.llvm.org/D81639
2020-07-05 15:54:12 +02:00
// MVE Instructions
MVE_VCTP8,
MVE_VCTP16,
MVE_VCTP32,
MVE_VCTP64,
MVE_VPST,
MVE_VPTv16i8,
MVE_VPTv8i16,
MVE_VPTv4i32,
MVE_VPTv16i8r,
MVE_VPTv8i16r,
MVE_VPTv4i32r,
MVE_VPTv16s8,
MVE_VPTv8s16,
MVE_VPTv4s32,
MVE_VPTv16s8r,
MVE_VPTv8s16r,
MVE_VPTv4s32r,
MVE_VPTv16u8,
MVE_VPTv8u16,
MVE_VPTv4u32,
MVE_VPTv16u8r,
MVE_VPTv8u16r,
MVE_VPTv4u32r,
MVE_VPTv8f16,
MVE_VPTv4f32,
MVE_VPTv8f16r,
MVE_VPTv4f32r,
MVE_VADC,
MVE_VADCI,
MVE_VSBC,
MVE_VSBCI,
MVE_VSHLC,
// FP Instructions
FLDMXIA,
FLDMXDB_UPD,
FLDMXIA_UPD,
FSTMXDB_UPD,
FSTMXIA,
FSTMXIA_UPD,
VLDR_FPCXTNS_off,
VLDR_FPCXTNS_off,
VLDR_FPCXTNS_post,
VLDR_FPCXTNS_pre,
VLDR_FPCXTS_off,
VLDR_FPCXTS_post,
VLDR_FPCXTS_pre,
VLDR_FPSCR_NZCVQC_off,
VLDR_FPSCR_NZCVQC_post,
VLDR_FPSCR_NZCVQC_pre,
VLDR_FPSCR_off,
VLDR_FPSCR_post,
VLDR_FPSCR_pre,
VLDR_P0_off,
VLDR_P0_post,
VLDR_P0_pre,
VLDR_VPR_off,
VLDR_VPR_post,
VLDR_VPR_pre,
VLLDM,
VLSTM,
VMRS,
VMRS_FPCXTNS,
VMRS_FPCXTS,
VMRS_FPEXC,
VMRS_FPINST,
VMRS_FPINST2,
VMRS_FPSCR_NZCVQC,
VMRS_FPSID,
VMRS_MVFR0,
VMRS_MVFR1,
VMRS_MVFR2,
VMRS_P0,
VMRS_VPR,
VMSR,
VMSR_FPCXTNS,
VMSR_FPCXTS,
VMSR_FPEXC,
VMSR_FPINST,
VMSR_FPINST2,
VMSR_FPSCR_NZCVQC,
VMSR_FPSID,
VMSR_P0,
VMSR_VPR,
VSCCLRMD,
VSCCLRMS,
VSTR_FPCXTNS_off,
VSTR_FPCXTNS_post,
VSTR_FPCXTNS_pre,
VSTR_FPCXTS_off,
VSTR_FPCXTS_post,
VSTR_FPCXTS_pre,
VSTR_FPSCR_NZCVQC_off,
VSTR_FPSCR_NZCVQC_post,
VSTR_FPSCR_NZCVQC_pre,
VSTR_FPSCR_off,
VSTR_FPSCR_post,
VSTR_FPSCR_pre,
VSTR_P0_off,
VSTR_P0_post,
VSTR_P0_pre,
VSTR_VPR_off,
VSTR_VPR_post,
VSTR_VPR_pre,
[ARM] Mark MVE loads/store as not having side effects The hasSideEffect parameter is usually automatically inferred from instruction patterns. For some of our MVE instructions, we do not have patterns though, such as for the pre/post inc loads and stores. This instead specifies the flag manually on the base MVE_VLDRSTR_base tablegen class, making sure we get this correct. This can help with scheduling multiple loads more optimally. Here I've added a unittest as a more direct form of testing. Differential Revision: https://reviews.llvm.org/D73117
2020-01-22 16:59:33 +01:00
};
LLVMInitializeARMTargetInfo();
LLVMInitializeARMTarget();
LLVMInitializeARMTargetMC();
[ARM] Replace arm vendor with none. NFC
2020-04-22 17:33:11 +02:00
auto TT(Triple::normalize("thumbv8.1m.main-none-none-eabi"));
[ARM] Mark MVE loads/store as not having side effects The hasSideEffect parameter is usually automatically inferred from instruction patterns. For some of our MVE instructions, we do not have patterns though, such as for the pre/post inc loads and stores. This instead specifies the flag manually on the base MVE_VLDRSTR_base tablegen class, making sure we get this correct. This can help with scheduling multiple loads more optimally. Here I've added a unittest as a more direct form of testing. Differential Revision: https://reviews.llvm.org/D73117
2020-01-22 16:59:33 +01:00
std::string Error;
const Target *T = TargetRegistry::lookupTarget(TT, Error);
if (!T) {
dbgs() << Error;
return;
}
TargetOptions Options;
auto TM = std::unique_ptr<LLVMTargetMachine>(
static_cast<LLVMTargetMachine *>(T->createTargetMachine(
TT, "generic", "", Options, None, None, CodeGenOpt::Default)));
Make llvm::StringRef to std::string conversions explicit. This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-28 20:23:46 +01:00
ARMSubtarget ST(TM->getTargetTriple(), std::string(TM->getTargetCPU()),
std::string(TM->getTargetFeatureString()),
[ARM] Mark MVE loads/store as not having side effects The hasSideEffect parameter is usually automatically inferred from instruction patterns. For some of our MVE instructions, we do not have patterns though, such as for the pre/post inc loads and stores. This instead specifies the flag manually on the base MVE_VLDRSTR_base tablegen class, making sure we get this correct. This can help with scheduling multiple loads more optimally. Here I've added a unittest as a more direct form of testing. Differential Revision: https://reviews.llvm.org/D73117
2020-01-22 16:59:33 +01:00
*static_cast<const ARMBaseTargetMachine *>(TM.get()), false);
const ARMBaseInstrInfo *TII = ST.getInstrInfo();
auto MII = TM->getMCInstrInfo();
[ARM] Make remaining MVE instruction predictable The unpredictable/hasSideEffects flag is usually inferred by tablegen from whether the instruction has a tablegen pattern (and that pattern only has a single output instruction). Now that the MVE intrinsics are all committed and producing code, the remaining instructions still marked as unpredictable need to be specially handled. This adds the flag directly to instructions that need it, notably the V*MLAL instructions and some of the MOV's. Differential Revision: https://reviews.llvm.org/D76910
2020-03-28 16:32:47 +01:00
for (unsigned Op = 0; Op < ARM::INSTRUCTION_LIST_END; ++Op) {
[ARM] Mark MVE loads/store as not having side effects The hasSideEffect parameter is usually automatically inferred from instruction patterns. For some of our MVE instructions, we do not have patterns though, such as for the pre/post inc loads and stores. This instead specifies the flag manually on the base MVE_VLDRSTR_base tablegen class, making sure we get this correct. This can help with scheduling multiple loads more optimally. Here I've added a unittest as a more direct form of testing. Differential Revision: https://reviews.llvm.org/D73117
2020-01-22 16:59:33 +01:00
const MCInstrDesc &Desc = TII->get(Op);
[ARM] More unpredictable VCVT instructions. These extra vcvt instructions were missed from 74ca67c109 because they live in a different Domain, but should be treated in the same way. Differential Revision: https://reviews.llvm.org/D83204
2020-07-21 07:49:04 +02:00
if ((Desc.TSFlags &
(ARMII::DomainMVE | ARMII::DomainVFP | ARMII::DomainNEONA8)) == 0)
[ARM] Make remaining MVE instruction predictable The unpredictable/hasSideEffects flag is usually inferred by tablegen from whether the instruction has a tablegen pattern (and that pattern only has a single output instruction). Now that the MVE intrinsics are all committed and producing code, the remaining instructions still marked as unpredictable need to be specially handled. This adds the flag directly to instructions that need it, notably the V*MLAL instructions and some of the MOV's. Differential Revision: https://reviews.llvm.org/D76910
2020-03-28 16:32:47 +01:00
continue;
if (UnpredictableOpcodes.count(Op))
continue;
[ARM] Mark MVE loads/store as not having side effects The hasSideEffect parameter is usually automatically inferred from instruction patterns. For some of our MVE instructions, we do not have patterns though, such as for the pre/post inc loads and stores. This instead specifies the flag manually on the base MVE_VLDRSTR_base tablegen class, making sure we get this correct. This can help with scheduling multiple loads more optimally. Here I've added a unittest as a more direct form of testing. Differential Revision: https://reviews.llvm.org/D73117
2020-01-22 16:59:33 +01:00
ASSERT_FALSE(Desc.hasUnmodeledSideEffects())
<< MII->getName(Op) << " has unexpected side effects";
}
}
Reference in New Issue Copy Permalink