2012-02-18 20:03:15 +08:00
|
|
|
//===-- PPCInstrAltivec.td - The PowerPC Altivec Extension -*- tablegen -*-===//
|
|
|
|
//
|
2006-03-25 15:51:43 +08:00
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-30 04:36:04 +08:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2012-02-18 20:03:15 +08:00
|
|
|
//
|
2006-03-25 15:51:43 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file describes the Altivec extension to the PowerPC instruction set.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Altivec transformation functions and pattern fragments.
|
|
|
|
//
|
|
|
|
|
2010-03-28 16:00:23 +08:00
|
|
|
// Since we canonicalize buildvectors to v16i8, all vnots "-1" operands will be
|
|
|
|
// of that type.
|
|
|
|
def vnot_ppc : PatFrag<(ops node:$in),
|
|
|
|
(xor node:$in, (bitconvert (v16i8 immAllOnesV)))>;
|
2009-04-28 02:41:29 +08:00
|
|
|
|
|
|
|
def vpkuhum_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isVPKUHUMShuffleMask(cast<ShuffleVectorSDNode>(N), false);
|
2006-04-07 01:23:16 +08:00
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vpkuwum_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isVPKUWUMShuffleMask(cast<ShuffleVectorSDNode>(N), false);
|
2006-04-07 01:23:16 +08:00
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vpkuhum_unary_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isVPKUHUMShuffleMask(cast<ShuffleVectorSDNode>(N), true);
|
2006-04-07 06:28:36 +08:00
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vpkuwum_unary_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isVPKUWUMShuffleMask(cast<ShuffleVectorSDNode>(N), true);
|
2006-04-07 06:28:36 +08:00
|
|
|
}]>;
|
|
|
|
|
|
|
|
|
2009-04-28 02:41:29 +08:00
|
|
|
def vmrglb_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
2010-03-09 02:44:04 +08:00
|
|
|
(vector_shuffle (v16i8 node:$lhs), node:$rhs), [{
|
2009-04-28 02:41:29 +08:00
|
|
|
return PPC::isVMRGLShuffleMask(cast<ShuffleVectorSDNode>(N), 1, false);
|
2006-04-07 05:11:54 +08:00
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vmrglh_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
2010-03-09 02:44:04 +08:00
|
|
|
(vector_shuffle (v16i8 node:$lhs), node:$rhs), [{
|
2009-04-28 02:41:29 +08:00
|
|
|
return PPC::isVMRGLShuffleMask(cast<ShuffleVectorSDNode>(N), 2, false);
|
2006-04-07 05:11:54 +08:00
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vmrglw_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
2010-03-09 02:44:04 +08:00
|
|
|
(vector_shuffle (v16i8 node:$lhs), node:$rhs), [{
|
2009-04-28 02:41:29 +08:00
|
|
|
return PPC::isVMRGLShuffleMask(cast<ShuffleVectorSDNode>(N), 4, false);
|
2006-04-07 05:11:54 +08:00
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vmrghb_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
2010-03-09 02:44:04 +08:00
|
|
|
(vector_shuffle (v16i8 node:$lhs), node:$rhs), [{
|
2009-04-28 02:41:29 +08:00
|
|
|
return PPC::isVMRGHShuffleMask(cast<ShuffleVectorSDNode>(N), 1, false);
|
2006-04-07 05:11:54 +08:00
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vmrghh_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
2010-03-09 02:44:04 +08:00
|
|
|
(vector_shuffle (v16i8 node:$lhs), node:$rhs), [{
|
2009-04-28 02:41:29 +08:00
|
|
|
return PPC::isVMRGHShuffleMask(cast<ShuffleVectorSDNode>(N), 2, false);
|
2006-04-07 05:11:54 +08:00
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vmrghw_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
2010-03-09 02:44:04 +08:00
|
|
|
(vector_shuffle (v16i8 node:$lhs), node:$rhs), [{
|
2009-04-28 02:41:29 +08:00
|
|
|
return PPC::isVMRGHShuffleMask(cast<ShuffleVectorSDNode>(N), 4, false);
|
2006-04-07 06:02:42 +08:00
|
|
|
}]>;
|
|
|
|
|
2009-04-28 02:41:29 +08:00
|
|
|
|
|
|
|
def vmrglb_unary_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
2010-03-09 02:44:04 +08:00
|
|
|
(vector_shuffle (v16i8 node:$lhs), node:$rhs), [{
|
2009-04-28 02:41:29 +08:00
|
|
|
return PPC::isVMRGLShuffleMask(cast<ShuffleVectorSDNode>(N), 1, true);
|
2006-04-07 06:02:42 +08:00
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vmrglh_unary_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isVMRGLShuffleMask(cast<ShuffleVectorSDNode>(N), 2, true);
|
2006-04-07 06:02:42 +08:00
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vmrglw_unary_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isVMRGLShuffleMask(cast<ShuffleVectorSDNode>(N), 4, true);
|
2006-04-07 06:02:42 +08:00
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vmrghb_unary_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isVMRGHShuffleMask(cast<ShuffleVectorSDNode>(N), 1, true);
|
2006-04-07 06:02:42 +08:00
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vmrghh_unary_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isVMRGHShuffleMask(cast<ShuffleVectorSDNode>(N), 2, true);
|
2006-04-07 06:02:42 +08:00
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vmrghw_unary_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isVMRGHShuffleMask(cast<ShuffleVectorSDNode>(N), 4, true);
|
2006-04-07 05:11:54 +08:00
|
|
|
}]>;
|
|
|
|
|
2009-04-28 02:41:29 +08:00
|
|
|
|
|
|
|
def VSLDOI_get_imm : SDNodeXForm<vector_shuffle, [{
|
2006-04-07 06:28:36 +08:00
|
|
|
return getI32Imm(PPC::isVSLDOIShuffleMask(N, false));
|
2006-04-07 02:26:28 +08:00
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vsldoi_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
2006-04-07 06:28:36 +08:00
|
|
|
return PPC::isVSLDOIShuffleMask(N, false) != -1;
|
2006-04-07 02:26:28 +08:00
|
|
|
}], VSLDOI_get_imm>;
|
|
|
|
|
2009-04-28 02:41:29 +08:00
|
|
|
|
2006-04-07 06:28:36 +08:00
|
|
|
/// VSLDOI_unary* - These are used to match vsldoi(X,X), which is turned into
|
2006-04-07 02:26:28 +08:00
|
|
|
/// vector_shuffle(X,undef,mask) by the dag combiner.
|
2009-04-28 02:41:29 +08:00
|
|
|
def VSLDOI_unary_get_imm : SDNodeXForm<vector_shuffle, [{
|
2006-04-07 06:28:36 +08:00
|
|
|
return getI32Imm(PPC::isVSLDOIShuffleMask(N, true));
|
2006-04-07 02:26:28 +08:00
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vsldoi_unary_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
2006-04-07 06:28:36 +08:00
|
|
|
return PPC::isVSLDOIShuffleMask(N, true) != -1;
|
|
|
|
}], VSLDOI_unary_get_imm>;
|
2006-04-07 02:26:28 +08:00
|
|
|
|
|
|
|
|
2006-04-05 01:25:31 +08:00
|
|
|
// VSPLT*_get_imm xform function: convert vector_shuffle mask to VSPLT* imm.
|
2009-04-28 02:41:29 +08:00
|
|
|
def VSPLTB_get_imm : SDNodeXForm<vector_shuffle, [{
|
2006-04-05 01:25:31 +08:00
|
|
|
return getI32Imm(PPC::getVSPLTImmediate(N, 1));
|
2006-03-25 15:51:43 +08:00
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vspltb_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isSplatShuffleMask(cast<ShuffleVectorSDNode>(N), 1);
|
2006-04-05 01:25:31 +08:00
|
|
|
}], VSPLTB_get_imm>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def VSPLTH_get_imm : SDNodeXForm<vector_shuffle, [{
|
2006-04-05 01:25:31 +08:00
|
|
|
return getI32Imm(PPC::getVSPLTImmediate(N, 2));
|
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vsplth_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isSplatShuffleMask(cast<ShuffleVectorSDNode>(N), 2);
|
2006-04-05 01:25:31 +08:00
|
|
|
}], VSPLTH_get_imm>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def VSPLTW_get_imm : SDNodeXForm<vector_shuffle, [{
|
2006-04-05 01:25:31 +08:00
|
|
|
return getI32Imm(PPC::getVSPLTImmediate(N, 4));
|
|
|
|
}]>;
|
2009-04-28 02:41:29 +08:00
|
|
|
def vspltw_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isSplatShuffleMask(cast<ShuffleVectorSDNode>(N), 4);
|
2006-04-05 01:25:31 +08:00
|
|
|
}], VSPLTW_get_imm>;
|
2006-03-25 15:51:43 +08:00
|
|
|
|
|
|
|
|
|
|
|
// VSPLTISB_get_imm xform function: convert build_vector to VSPLTISB imm.
|
|
|
|
def VSPLTISB_get_imm : SDNodeXForm<build_vector, [{
|
2006-04-13 01:37:20 +08:00
|
|
|
return PPC::get_VSPLTI_elt(N, 1, *CurDAG);
|
2006-03-25 15:51:43 +08:00
|
|
|
}]>;
|
|
|
|
def vecspltisb : PatLeaf<(build_vector), [{
|
2008-08-29 05:40:38 +08:00
|
|
|
return PPC::get_VSPLTI_elt(N, 1, *CurDAG).getNode() != 0;
|
2006-03-25 15:51:43 +08:00
|
|
|
}], VSPLTISB_get_imm>;
|
|
|
|
|
|
|
|
// VSPLTISH_get_imm xform function: convert build_vector to VSPLTISH imm.
|
|
|
|
def VSPLTISH_get_imm : SDNodeXForm<build_vector, [{
|
2006-04-13 01:37:20 +08:00
|
|
|
return PPC::get_VSPLTI_elt(N, 2, *CurDAG);
|
2006-03-25 15:51:43 +08:00
|
|
|
}]>;
|
|
|
|
def vecspltish : PatLeaf<(build_vector), [{
|
2008-08-29 05:40:38 +08:00
|
|
|
return PPC::get_VSPLTI_elt(N, 2, *CurDAG).getNode() != 0;
|
2006-03-25 15:51:43 +08:00
|
|
|
}], VSPLTISH_get_imm>;
|
|
|
|
|
|
|
|
// VSPLTISW_get_imm xform function: convert build_vector to VSPLTISW imm.
|
|
|
|
def VSPLTISW_get_imm : SDNodeXForm<build_vector, [{
|
2006-04-13 01:37:20 +08:00
|
|
|
return PPC::get_VSPLTI_elt(N, 4, *CurDAG);
|
2006-03-25 15:51:43 +08:00
|
|
|
}]>;
|
|
|
|
def vecspltisw : PatLeaf<(build_vector), [{
|
2008-08-29 05:40:38 +08:00
|
|
|
return PPC::get_VSPLTI_elt(N, 4, *CurDAG).getNode() != 0;
|
2006-03-25 15:51:43 +08:00
|
|
|
}], VSPLTISW_get_imm>;
|
|
|
|
|
2006-03-31 07:21:27 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Helpers for defining instructions that directly correspond to intrinsics.
|
|
|
|
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
// VA1a_Int_Ty - A VAForm_1a intrinsic definition of specific type.
|
|
|
|
class VA1a_Int_Ty<bits<6> xo, string opc, Intrinsic IntID, ValueType Ty>
|
2013-04-27 00:53:15 +08:00
|
|
|
: VAForm_1a<xo, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB, vrrc:$vC),
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
!strconcat(opc, " $vD, $vA, $vB, $vC"), VecFP,
|
|
|
|
[(set Ty:$vD, (IntID Ty:$vA, Ty:$vB, Ty:$vC))]>;
|
|
|
|
|
|
|
|
// VA1a_Int_Ty2 - A VAForm_1a intrinsic definition where the type of the
|
|
|
|
// inputs doesn't match the type of the output.
|
|
|
|
class VA1a_Int_Ty2<bits<6> xo, string opc, Intrinsic IntID, ValueType OutTy,
|
|
|
|
ValueType InTy>
|
2013-04-27 00:53:15 +08:00
|
|
|
: VAForm_1a<xo, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB, vrrc:$vC),
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
!strconcat(opc, " $vD, $vA, $vB, $vC"), VecFP,
|
|
|
|
[(set OutTy:$vD, (IntID InTy:$vA, InTy:$vB, InTy:$vC))]>;
|
|
|
|
|
|
|
|
// VA1a_Int_Ty3 - A VAForm_1a intrinsic definition where there are two
|
|
|
|
// input types and an output type.
|
|
|
|
class VA1a_Int_Ty3<bits<6> xo, string opc, Intrinsic IntID, ValueType OutTy,
|
|
|
|
ValueType In1Ty, ValueType In2Ty>
|
2013-04-27 00:53:15 +08:00
|
|
|
: VAForm_1a<xo, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB, vrrc:$vC),
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
!strconcat(opc, " $vD, $vA, $vB, $vC"), VecFP,
|
|
|
|
[(set OutTy:$vD,
|
|
|
|
(IntID In1Ty:$vA, In1Ty:$vB, In2Ty:$vC))]>;
|
|
|
|
|
|
|
|
// VX1_Int_Ty - A VXForm_1 intrinsic definition of specific type.
|
|
|
|
class VX1_Int_Ty<bits<11> xo, string opc, Intrinsic IntID, ValueType Ty>
|
2013-04-27 00:53:15 +08:00
|
|
|
: VXForm_1<xo, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
!strconcat(opc, " $vD, $vA, $vB"), VecFP,
|
|
|
|
[(set Ty:$vD, (IntID Ty:$vA, Ty:$vB))]>;
|
|
|
|
|
|
|
|
// VX1_Int_Ty2 - A VXForm_1 intrinsic definition where the type of the
|
|
|
|
// inputs doesn't match the type of the output.
|
|
|
|
class VX1_Int_Ty2<bits<11> xo, string opc, Intrinsic IntID, ValueType OutTy,
|
|
|
|
ValueType InTy>
|
2013-04-27 00:53:15 +08:00
|
|
|
: VXForm_1<xo, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
!strconcat(opc, " $vD, $vA, $vB"), VecFP,
|
|
|
|
[(set OutTy:$vD, (IntID InTy:$vA, InTy:$vB))]>;
|
|
|
|
|
|
|
|
// VX1_Int_Ty3 - A VXForm_1 intrinsic definition where there are two
|
|
|
|
// input types and an output type.
|
|
|
|
class VX1_Int_Ty3<bits<11> xo, string opc, Intrinsic IntID, ValueType OutTy,
|
|
|
|
ValueType In1Ty, ValueType In2Ty>
|
2013-04-27 00:53:15 +08:00
|
|
|
: VXForm_1<xo, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
!strconcat(opc, " $vD, $vA, $vB"), VecFP,
|
|
|
|
[(set OutTy:$vD, (IntID In1Ty:$vA, In2Ty:$vB))]>;
|
|
|
|
|
|
|
|
// VX2_Int_SP - A VXForm_2 intrinsic definition of vector single-precision type.
|
|
|
|
class VX2_Int_SP<bits<11> xo, string opc, Intrinsic IntID>
|
2013-04-27 00:53:15 +08:00
|
|
|
: VXForm_2<xo, (outs vrrc:$vD), (ins vrrc:$vB),
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
!strconcat(opc, " $vD, $vB"), VecFP,
|
|
|
|
[(set v4f32:$vD, (IntID v4f32:$vB))]>;
|
|
|
|
|
|
|
|
// VX2_Int_Ty2 - A VXForm_2 intrinsic definition where the type of the
|
|
|
|
// inputs doesn't match the type of the output.
|
|
|
|
class VX2_Int_Ty2<bits<11> xo, string opc, Intrinsic IntID, ValueType OutTy,
|
|
|
|
ValueType InTy>
|
2013-04-27 00:53:15 +08:00
|
|
|
: VXForm_2<xo, (outs vrrc:$vD), (ins vrrc:$vB),
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
!strconcat(opc, " $vD, $vB"), VecFP,
|
|
|
|
[(set OutTy:$vD, (IntID InTy:$vB))]>;
|
|
|
|
|
2006-03-25 15:51:43 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Instruction Definitions.
|
|
|
|
|
2013-03-15 21:21:21 +08:00
|
|
|
def HasAltivec : Predicate<"PPCSubTarget.hasAltivec()">;
|
|
|
|
let Predicates = [HasAltivec] in {
|
|
|
|
|
2013-03-26 18:57:16 +08:00
|
|
|
let isCodeGenOnly = 1 in {
|
2007-09-05 12:05:20 +08:00
|
|
|
def DSS : DSS_Form<822, (outs),
|
|
|
|
(ins u5imm:$ZERO0, u5imm:$STRM,u5imm:$ZERO1,u5imm:$ZERO2),
|
2012-04-01 12:44:16 +08:00
|
|
|
"dss $STRM", LdStLoad /*FIXME*/, []>;
|
2007-09-05 12:05:20 +08:00
|
|
|
def DSSALL : DSS_Form<822, (outs),
|
|
|
|
(ins u5imm:$ONE, u5imm:$ZERO0,u5imm:$ZERO1,u5imm:$ZERO2),
|
2012-04-01 12:44:16 +08:00
|
|
|
"dssall", LdStLoad /*FIXME*/, []>;
|
2007-09-05 12:05:20 +08:00
|
|
|
def DST : DSS_Form<342, (outs),
|
2013-04-27 00:53:15 +08:00
|
|
|
(ins u5imm:$ZERO, u5imm:$STRM, gprc:$rA, gprc:$rB),
|
2012-04-01 12:44:16 +08:00
|
|
|
"dst $rA, $rB, $STRM", LdStLoad /*FIXME*/, []>;
|
2007-09-05 12:05:20 +08:00
|
|
|
def DSTT : DSS_Form<342, (outs),
|
2013-04-27 00:53:15 +08:00
|
|
|
(ins u5imm:$ONE, u5imm:$STRM, gprc:$rA, gprc:$rB),
|
2012-04-01 12:44:16 +08:00
|
|
|
"dstt $rA, $rB, $STRM", LdStLoad /*FIXME*/, []>;
|
2007-09-05 12:05:20 +08:00
|
|
|
def DSTST : DSS_Form<374, (outs),
|
2013-04-27 00:53:15 +08:00
|
|
|
(ins u5imm:$ZERO, u5imm:$STRM, gprc:$rA, gprc:$rB),
|
2012-04-01 12:44:16 +08:00
|
|
|
"dstst $rA, $rB, $STRM", LdStLoad /*FIXME*/, []>;
|
2007-09-05 12:05:20 +08:00
|
|
|
def DSTSTT : DSS_Form<374, (outs),
|
2013-04-27 00:53:15 +08:00
|
|
|
(ins u5imm:$ONE, u5imm:$STRM, gprc:$rA, gprc:$rB),
|
2012-04-01 12:44:16 +08:00
|
|
|
"dststt $rA, $rB, $STRM", LdStLoad /*FIXME*/, []>;
|
2007-09-05 12:05:20 +08:00
|
|
|
|
|
|
|
def DST64 : DSS_Form<342, (outs),
|
2013-04-27 00:53:15 +08:00
|
|
|
(ins u5imm:$ZERO, u5imm:$STRM, g8rc:$rA, gprc:$rB),
|
2012-04-01 12:44:16 +08:00
|
|
|
"dst $rA, $rB, $STRM", LdStLoad /*FIXME*/, []>;
|
2007-09-05 12:05:20 +08:00
|
|
|
def DSTT64 : DSS_Form<342, (outs),
|
2013-04-27 00:53:15 +08:00
|
|
|
(ins u5imm:$ONE, u5imm:$STRM, g8rc:$rA, gprc:$rB),
|
2012-04-01 12:44:16 +08:00
|
|
|
"dstt $rA, $rB, $STRM", LdStLoad /*FIXME*/, []>;
|
2007-09-05 12:05:20 +08:00
|
|
|
def DSTST64 : DSS_Form<374, (outs),
|
2013-04-27 00:53:15 +08:00
|
|
|
(ins u5imm:$ZERO, u5imm:$STRM, g8rc:$rA, gprc:$rB),
|
2012-04-01 12:44:16 +08:00
|
|
|
"dstst $rA, $rB, $STRM", LdStLoad /*FIXME*/, []>;
|
2007-09-05 12:05:20 +08:00
|
|
|
def DSTSTT64 : DSS_Form<374, (outs),
|
2013-04-27 00:53:15 +08:00
|
|
|
(ins u5imm:$ONE, u5imm:$STRM, g8rc:$rA, gprc:$rB),
|
2012-04-01 12:44:16 +08:00
|
|
|
"dststt $rA, $rB, $STRM", LdStLoad /*FIXME*/, []>;
|
2013-03-26 18:57:16 +08:00
|
|
|
}
|
2006-04-06 06:27:14 +08:00
|
|
|
|
2013-04-27 00:53:15 +08:00
|
|
|
def MFVSCR : VXForm_4<1540, (outs vrrc:$vD), (ins),
|
2012-04-01 12:44:16 +08:00
|
|
|
"mfvscr $vD", LdStStore,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v8i16:$vD, (int_ppc_altivec_mfvscr))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def MTVSCR : VXForm_5<1604, (outs), (ins vrrc:$vB),
|
2012-04-01 12:44:16 +08:00
|
|
|
"mtvscr $vB", LdStLoad,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(int_ppc_altivec_mtvscr v4i32:$vB)]>;
|
2006-04-05 08:03:57 +08:00
|
|
|
|
2008-12-04 02:15:48 +08:00
|
|
|
let canFoldAsLoad = 1, PPC970_Unit = 2 in { // Loads.
|
2013-04-27 00:53:15 +08:00
|
|
|
def LVEBX: XForm_1<31, 7, (outs vrrc:$vD), (ins memrr:$src),
|
2012-04-01 12:44:16 +08:00
|
|
|
"lvebx $vD, $src", LdStLoad,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v16i8:$vD, (int_ppc_altivec_lvebx xoaddr:$src))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def LVEHX: XForm_1<31, 39, (outs vrrc:$vD), (ins memrr:$src),
|
2012-04-01 12:44:16 +08:00
|
|
|
"lvehx $vD, $src", LdStLoad,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v8i16:$vD, (int_ppc_altivec_lvehx xoaddr:$src))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def LVEWX: XForm_1<31, 71, (outs vrrc:$vD), (ins memrr:$src),
|
2012-04-01 12:44:16 +08:00
|
|
|
"lvewx $vD, $src", LdStLoad,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4i32:$vD, (int_ppc_altivec_lvewx xoaddr:$src))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def LVX : XForm_1<31, 103, (outs vrrc:$vD), (ins memrr:$src),
|
2012-04-01 12:44:16 +08:00
|
|
|
"lvx $vD, $src", LdStLoad,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4i32:$vD, (int_ppc_altivec_lvx xoaddr:$src))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def LVXL : XForm_1<31, 359, (outs vrrc:$vD), (ins memrr:$src),
|
2012-04-01 12:44:16 +08:00
|
|
|
"lvxl $vD, $src", LdStLoad,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4i32:$vD, (int_ppc_altivec_lvxl xoaddr:$src))]>;
|
2006-03-25 15:51:43 +08:00
|
|
|
}
|
|
|
|
|
2013-04-27 00:53:15 +08:00
|
|
|
def LVSL : XForm_1<31, 6, (outs vrrc:$vD), (ins memrr:$src),
|
2012-04-01 12:44:16 +08:00
|
|
|
"lvsl $vD, $src", LdStLoad,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v16i8:$vD, (int_ppc_altivec_lvsl xoaddr:$src))]>,
|
2006-03-31 07:07:36 +08:00
|
|
|
PPC970_Unit_LSU;
|
2013-04-27 00:53:15 +08:00
|
|
|
def LVSR : XForm_1<31, 38, (outs vrrc:$vD), (ins memrr:$src),
|
2012-04-01 12:44:16 +08:00
|
|
|
"lvsr $vD, $src", LdStLoad,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v16i8:$vD, (int_ppc_altivec_lvsr xoaddr:$src))]>,
|
2006-03-31 07:07:36 +08:00
|
|
|
PPC970_Unit_LSU;
|
2006-03-25 15:51:43 +08:00
|
|
|
|
2008-01-06 13:53:26 +08:00
|
|
|
let PPC970_Unit = 2 in { // Stores.
|
2013-04-27 00:53:15 +08:00
|
|
|
def STVEBX: XForm_8<31, 135, (outs), (ins vrrc:$rS, memrr:$dst),
|
2012-04-01 12:44:16 +08:00
|
|
|
"stvebx $rS, $dst", LdStStore,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(int_ppc_altivec_stvebx v16i8:$rS, xoaddr:$dst)]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def STVEHX: XForm_8<31, 167, (outs), (ins vrrc:$rS, memrr:$dst),
|
2012-04-01 12:44:16 +08:00
|
|
|
"stvehx $rS, $dst", LdStStore,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(int_ppc_altivec_stvehx v8i16:$rS, xoaddr:$dst)]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def STVEWX: XForm_8<31, 199, (outs), (ins vrrc:$rS, memrr:$dst),
|
2012-04-01 12:44:16 +08:00
|
|
|
"stvewx $rS, $dst", LdStStore,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(int_ppc_altivec_stvewx v4i32:$rS, xoaddr:$dst)]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def STVX : XForm_8<31, 231, (outs), (ins vrrc:$rS, memrr:$dst),
|
2012-04-01 12:44:16 +08:00
|
|
|
"stvx $rS, $dst", LdStStore,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(int_ppc_altivec_stvx v4i32:$rS, xoaddr:$dst)]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def STVXL : XForm_8<31, 487, (outs), (ins vrrc:$rS, memrr:$dst),
|
2012-04-01 12:44:16 +08:00
|
|
|
"stvxl $rS, $dst", LdStStore,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(int_ppc_altivec_stvxl v4i32:$rS, xoaddr:$dst)]>;
|
2006-03-25 15:51:43 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
let PPC970_Unit = 5 in { // VALU Operations.
|
|
|
|
// VA-Form instructions. 3-input AltiVec ops.
|
2013-04-27 00:53:15 +08:00
|
|
|
def VMADDFP : VAForm_1<46, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vC, vrrc:$vB),
|
2006-03-25 15:51:43 +08:00
|
|
|
"vmaddfp $vD, $vA, $vC, $vB", VecFP,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4f32:$vD,
|
|
|
|
(fma v4f32:$vA, v4f32:$vC, v4f32:$vB))]>;
|
2013-04-03 22:40:16 +08:00
|
|
|
|
|
|
|
// FIXME: The fma+fneg pattern won't match because fneg is not legal.
|
2013-04-27 00:53:15 +08:00
|
|
|
def VNMSUBFP: VAForm_1<47, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vC, vrrc:$vB),
|
2006-03-25 15:51:43 +08:00
|
|
|
"vnmsubfp $vD, $vA, $vC, $vB", VecFP,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4f32:$vD, (fneg (fma v4f32:$vA, v4f32:$vC,
|
|
|
|
(fneg v4f32:$vB))))]>;
|
2006-04-05 08:49:48 +08:00
|
|
|
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def VMHADDSHS : VA1a_Int_Ty<32, "vmhaddshs", int_ppc_altivec_vmhaddshs, v8i16>;
|
|
|
|
def VMHRADDSHS : VA1a_Int_Ty<33, "vmhraddshs", int_ppc_altivec_vmhraddshs,
|
|
|
|
v8i16>;
|
|
|
|
def VMLADDUHM : VA1a_Int_Ty<34, "vmladduhm", int_ppc_altivec_vmladduhm, v8i16>;
|
|
|
|
|
|
|
|
def VPERM : VA1a_Int_Ty3<43, "vperm", int_ppc_altivec_vperm,
|
|
|
|
v4i32, v4i32, v16i8>;
|
|
|
|
def VSEL : VA1a_Int_Ty<42, "vsel", int_ppc_altivec_vsel, v4i32>;
|
2006-04-01 04:00:35 +08:00
|
|
|
|
2006-04-07 02:26:28 +08:00
|
|
|
// Shuffles.
|
2013-04-27 00:53:15 +08:00
|
|
|
def VSLDOI : VAForm_2<44, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB, u5imm:$SH),
|
2006-03-26 08:41:48 +08:00
|
|
|
"vsldoi $vD, $vA, $vB, $SH", VecFP,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v16i8:$vD,
|
|
|
|
(vsldoi_shuffle:$SH v16i8:$vA, v16i8:$vB))]>;
|
2006-03-25 15:51:43 +08:00
|
|
|
|
|
|
|
// VX-Form instructions. AltiVec arithmetic ops.
|
2013-04-27 00:53:15 +08:00
|
|
|
def VADDFP : VXForm_1<10, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-03-25 15:51:43 +08:00
|
|
|
"vaddfp $vD, $vA, $vB", VecFP,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4f32:$vD, (fadd v4f32:$vA, v4f32:$vB))]>;
|
2006-03-26 10:39:02 +08:00
|
|
|
|
2013-04-27 00:53:15 +08:00
|
|
|
def VADDUBM : VXForm_1<0, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-03-26 10:39:02 +08:00
|
|
|
"vaddubm $vD, $vA, $vB", VecGeneral,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v16i8:$vD, (add v16i8:$vA, v16i8:$vB))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VADDUHM : VXForm_1<64, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-03-26 10:39:02 +08:00
|
|
|
"vadduhm $vD, $vA, $vB", VecGeneral,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v8i16:$vD, (add v8i16:$vA, v8i16:$vB))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VADDUWM : VXForm_1<128, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-03-26 10:39:02 +08:00
|
|
|
"vadduwm $vD, $vA, $vB", VecGeneral,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4i32:$vD, (add v4i32:$vA, v4i32:$vB))]>;
|
2006-03-26 10:39:02 +08:00
|
|
|
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def VADDCUW : VX1_Int_Ty<384, "vaddcuw", int_ppc_altivec_vaddcuw, v4i32>;
|
|
|
|
def VADDSBS : VX1_Int_Ty<768, "vaddsbs", int_ppc_altivec_vaddsbs, v16i8>;
|
|
|
|
def VADDSHS : VX1_Int_Ty<832, "vaddshs", int_ppc_altivec_vaddshs, v8i16>;
|
|
|
|
def VADDSWS : VX1_Int_Ty<896, "vaddsws", int_ppc_altivec_vaddsws, v4i32>;
|
|
|
|
def VADDUBS : VX1_Int_Ty<512, "vaddubs", int_ppc_altivec_vaddubs, v16i8>;
|
|
|
|
def VADDUHS : VX1_Int_Ty<576, "vadduhs", int_ppc_altivec_vadduhs, v8i16>;
|
|
|
|
def VADDUWS : VX1_Int_Ty<640, "vadduws", int_ppc_altivec_vadduws, v4i32>;
|
2006-04-01 06:41:56 +08:00
|
|
|
|
2006-03-26 10:39:02 +08:00
|
|
|
|
2013-04-27 00:53:15 +08:00
|
|
|
def VAND : VXForm_1<1028, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-03-26 06:16:05 +08:00
|
|
|
"vand $vD, $vA, $vB", VecFP,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v4i32:$vD, (and v4i32:$vA, v4i32:$vB))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VANDC : VXForm_1<1092, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-03-26 06:16:05 +08:00
|
|
|
"vandc $vD, $vA, $vB", VecFP,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v4i32:$vD, (and v4i32:$vA,
|
|
|
|
(vnot_ppc v4i32:$vB)))]>;
|
2006-03-26 06:16:05 +08:00
|
|
|
|
2013-04-27 00:53:15 +08:00
|
|
|
def VCFSX : VXForm_1<842, (outs vrrc:$vD), (ins u5imm:$UIMM, vrrc:$vB),
|
2006-03-25 15:51:43 +08:00
|
|
|
"vcfsx $vD, $vB, $UIMM", VecFP,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4f32:$vD,
|
|
|
|
(int_ppc_altivec_vcfsx v4i32:$vB, imm:$UIMM))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VCFUX : VXForm_1<778, (outs vrrc:$vD), (ins u5imm:$UIMM, vrrc:$vB),
|
2006-03-25 15:51:43 +08:00
|
|
|
"vcfux $vD, $vB, $UIMM", VecFP,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4f32:$vD,
|
|
|
|
(int_ppc_altivec_vcfux v4i32:$vB, imm:$UIMM))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VCTSXS : VXForm_1<970, (outs vrrc:$vD), (ins u5imm:$UIMM, vrrc:$vB),
|
2006-03-25 15:51:43 +08:00
|
|
|
"vctsxs $vD, $vB, $UIMM", VecFP,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4i32:$vD,
|
|
|
|
(int_ppc_altivec_vctsxs v4f32:$vB, imm:$UIMM))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VCTUXS : VXForm_1<906, (outs vrrc:$vD), (ins u5imm:$UIMM, vrrc:$vB),
|
2006-03-25 15:51:43 +08:00
|
|
|
"vctuxs $vD, $vB, $UIMM", VecFP,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4i32:$vD,
|
|
|
|
(int_ppc_altivec_vctuxs v4f32:$vB, imm:$UIMM))]>;
|
2012-10-09 01:27:24 +08:00
|
|
|
|
|
|
|
// Defines with the UIM field set to 0 for floating-point
|
|
|
|
// to integer (fp_to_sint/fp_to_uint) conversions and integer
|
|
|
|
// to floating-point (sint_to_fp/uint_to_fp) conversions.
|
2013-07-03 20:51:09 +08:00
|
|
|
let isCodeGenOnly = 1, VA = 0 in {
|
2013-04-27 00:53:15 +08:00
|
|
|
def VCFSX_0 : VXForm_1<842, (outs vrrc:$vD), (ins vrrc:$vB),
|
2012-10-09 01:27:24 +08:00
|
|
|
"vcfsx $vD, $vB, 0", VecFP,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4f32:$vD,
|
|
|
|
(int_ppc_altivec_vcfsx v4i32:$vB, 0))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VCTUXS_0 : VXForm_1<906, (outs vrrc:$vD), (ins vrrc:$vB),
|
2012-10-09 01:27:24 +08:00
|
|
|
"vctuxs $vD, $vB, 0", VecFP,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4i32:$vD,
|
|
|
|
(int_ppc_altivec_vctuxs v4f32:$vB, 0))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VCFUX_0 : VXForm_1<778, (outs vrrc:$vD), (ins vrrc:$vB),
|
2012-10-09 01:27:24 +08:00
|
|
|
"vcfux $vD, $vB, 0", VecFP,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4f32:$vD,
|
|
|
|
(int_ppc_altivec_vcfux v4i32:$vB, 0))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VCTSXS_0 : VXForm_1<970, (outs vrrc:$vD), (ins vrrc:$vB),
|
2012-10-09 01:27:24 +08:00
|
|
|
"vctsxs $vD, $vB, 0", VecFP,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4i32:$vD,
|
|
|
|
(int_ppc_altivec_vctsxs v4f32:$vB, 0))]>;
|
2012-10-09 01:27:24 +08:00
|
|
|
}
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def VEXPTEFP : VX2_Int_SP<394, "vexptefp", int_ppc_altivec_vexptefp>;
|
|
|
|
def VLOGEFP : VX2_Int_SP<458, "vlogefp", int_ppc_altivec_vlogefp>;
|
|
|
|
|
|
|
|
def VAVGSB : VX1_Int_Ty<1282, "vavgsb", int_ppc_altivec_vavgsb, v16i8>;
|
|
|
|
def VAVGSH : VX1_Int_Ty<1346, "vavgsh", int_ppc_altivec_vavgsh, v8i16>;
|
|
|
|
def VAVGSW : VX1_Int_Ty<1410, "vavgsw", int_ppc_altivec_vavgsw, v4i32>;
|
|
|
|
def VAVGUB : VX1_Int_Ty<1026, "vavgub", int_ppc_altivec_vavgub, v16i8>;
|
|
|
|
def VAVGUH : VX1_Int_Ty<1090, "vavguh", int_ppc_altivec_vavguh, v8i16>;
|
|
|
|
def VAVGUW : VX1_Int_Ty<1154, "vavguw", int_ppc_altivec_vavguw, v4i32>;
|
|
|
|
|
|
|
|
def VMAXFP : VX1_Int_Ty<1034, "vmaxfp", int_ppc_altivec_vmaxfp, v4f32>;
|
|
|
|
def VMAXSB : VX1_Int_Ty< 258, "vmaxsb", int_ppc_altivec_vmaxsb, v16i8>;
|
|
|
|
def VMAXSH : VX1_Int_Ty< 322, "vmaxsh", int_ppc_altivec_vmaxsh, v8i16>;
|
|
|
|
def VMAXSW : VX1_Int_Ty< 386, "vmaxsw", int_ppc_altivec_vmaxsw, v4i32>;
|
|
|
|
def VMAXUB : VX1_Int_Ty< 2, "vmaxub", int_ppc_altivec_vmaxub, v16i8>;
|
|
|
|
def VMAXUH : VX1_Int_Ty< 66, "vmaxuh", int_ppc_altivec_vmaxuh, v8i16>;
|
|
|
|
def VMAXUW : VX1_Int_Ty< 130, "vmaxuw", int_ppc_altivec_vmaxuw, v4i32>;
|
|
|
|
def VMINFP : VX1_Int_Ty<1098, "vminfp", int_ppc_altivec_vminfp, v4f32>;
|
|
|
|
def VMINSB : VX1_Int_Ty< 770, "vminsb", int_ppc_altivec_vminsb, v16i8>;
|
|
|
|
def VMINSH : VX1_Int_Ty< 834, "vminsh", int_ppc_altivec_vminsh, v8i16>;
|
|
|
|
def VMINSW : VX1_Int_Ty< 898, "vminsw", int_ppc_altivec_vminsw, v4i32>;
|
|
|
|
def VMINUB : VX1_Int_Ty< 514, "vminub", int_ppc_altivec_vminub, v16i8>;
|
|
|
|
def VMINUH : VX1_Int_Ty< 578, "vminuh", int_ppc_altivec_vminuh, v8i16>;
|
|
|
|
def VMINUW : VX1_Int_Ty< 642, "vminuw", int_ppc_altivec_vminuw, v4i32>;
|
2006-03-31 07:07:36 +08:00
|
|
|
|
2013-04-27 00:53:15 +08:00
|
|
|
def VMRGHB : VXForm_1< 12, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-04-07 05:11:54 +08:00
|
|
|
"vmrghb $vD, $vA, $vB", VecFP,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v16i8:$vD, (vmrghb_shuffle v16i8:$vA, v16i8:$vB))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VMRGHH : VXForm_1< 76, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-04-07 05:11:54 +08:00
|
|
|
"vmrghh $vD, $vA, $vB", VecFP,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v16i8:$vD, (vmrghh_shuffle v16i8:$vA, v16i8:$vB))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VMRGHW : VXForm_1<140, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-04-07 05:11:54 +08:00
|
|
|
"vmrghw $vD, $vA, $vB", VecFP,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v16i8:$vD, (vmrghw_shuffle v16i8:$vA, v16i8:$vB))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VMRGLB : VXForm_1<268, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-04-07 05:11:54 +08:00
|
|
|
"vmrglb $vD, $vA, $vB", VecFP,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v16i8:$vD, (vmrglb_shuffle v16i8:$vA, v16i8:$vB))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VMRGLH : VXForm_1<332, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-04-07 05:11:54 +08:00
|
|
|
"vmrglh $vD, $vA, $vB", VecFP,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v16i8:$vD, (vmrglh_shuffle v16i8:$vA, v16i8:$vB))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VMRGLW : VXForm_1<396, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-04-07 05:11:54 +08:00
|
|
|
"vmrglw $vD, $vA, $vB", VecFP,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v16i8:$vD, (vmrglw_shuffle v16i8:$vA, v16i8:$vB))]>;
|
2006-03-31 07:21:27 +08:00
|
|
|
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def VMSUMMBM : VA1a_Int_Ty3<37, "vmsummbm", int_ppc_altivec_vmsummbm,
|
|
|
|
v4i32, v16i8, v4i32>;
|
|
|
|
def VMSUMSHM : VA1a_Int_Ty3<40, "vmsumshm", int_ppc_altivec_vmsumshm,
|
|
|
|
v4i32, v8i16, v4i32>;
|
|
|
|
def VMSUMSHS : VA1a_Int_Ty3<41, "vmsumshs", int_ppc_altivec_vmsumshs,
|
|
|
|
v4i32, v8i16, v4i32>;
|
|
|
|
def VMSUMUBM : VA1a_Int_Ty3<36, "vmsumubm", int_ppc_altivec_vmsumubm,
|
|
|
|
v4i32, v16i8, v4i32>;
|
|
|
|
def VMSUMUHM : VA1a_Int_Ty3<38, "vmsumuhm", int_ppc_altivec_vmsumuhm,
|
|
|
|
v4i32, v8i16, v4i32>;
|
|
|
|
def VMSUMUHS : VA1a_Int_Ty3<39, "vmsumuhs", int_ppc_altivec_vmsumuhs,
|
|
|
|
v4i32, v8i16, v4i32>;
|
|
|
|
|
|
|
|
def VMULESB : VX1_Int_Ty2<776, "vmulesb", int_ppc_altivec_vmulesb,
|
|
|
|
v8i16, v16i8>;
|
|
|
|
def VMULESH : VX1_Int_Ty2<840, "vmulesh", int_ppc_altivec_vmulesh,
|
|
|
|
v4i32, v8i16>;
|
|
|
|
def VMULEUB : VX1_Int_Ty2<520, "vmuleub", int_ppc_altivec_vmuleub,
|
|
|
|
v8i16, v16i8>;
|
|
|
|
def VMULEUH : VX1_Int_Ty2<584, "vmuleuh", int_ppc_altivec_vmuleuh,
|
|
|
|
v4i32, v8i16>;
|
|
|
|
def VMULOSB : VX1_Int_Ty2<264, "vmulosb", int_ppc_altivec_vmulosb,
|
|
|
|
v8i16, v16i8>;
|
|
|
|
def VMULOSH : VX1_Int_Ty2<328, "vmulosh", int_ppc_altivec_vmulosh,
|
|
|
|
v4i32, v8i16>;
|
|
|
|
def VMULOUB : VX1_Int_Ty2< 8, "vmuloub", int_ppc_altivec_vmuloub,
|
|
|
|
v8i16, v16i8>;
|
|
|
|
def VMULOUH : VX1_Int_Ty2< 72, "vmulouh", int_ppc_altivec_vmulouh,
|
|
|
|
v4i32, v8i16>;
|
2006-03-31 07:07:36 +08:00
|
|
|
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def VREFP : VX2_Int_SP<266, "vrefp", int_ppc_altivec_vrefp>;
|
|
|
|
def VRFIM : VX2_Int_SP<714, "vrfim", int_ppc_altivec_vrfim>;
|
|
|
|
def VRFIN : VX2_Int_SP<522, "vrfin", int_ppc_altivec_vrfin>;
|
|
|
|
def VRFIP : VX2_Int_SP<650, "vrfip", int_ppc_altivec_vrfip>;
|
|
|
|
def VRFIZ : VX2_Int_SP<586, "vrfiz", int_ppc_altivec_vrfiz>;
|
|
|
|
def VRSQRTEFP : VX2_Int_SP<330, "vrsqrtefp", int_ppc_altivec_vrsqrtefp>;
|
2006-03-31 07:21:27 +08:00
|
|
|
|
2013-04-26 23:39:57 +08:00
|
|
|
def VSUBCUW : VX1_Int_Ty<1408, "vsubcuw", int_ppc_altivec_vsubcuw, v4i32>;
|
2006-03-31 07:21:27 +08:00
|
|
|
|
2013-04-27 00:53:15 +08:00
|
|
|
def VSUBFP : VXForm_1<74, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-03-31 07:21:27 +08:00
|
|
|
"vsubfp $vD, $vA, $vB", VecGeneral,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4f32:$vD, (fsub v4f32:$vA, v4f32:$vB))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VSUBUBM : VXForm_1<1024, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-03-26 10:39:02 +08:00
|
|
|
"vsububm $vD, $vA, $vB", VecGeneral,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v16i8:$vD, (sub v16i8:$vA, v16i8:$vB))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VSUBUHM : VXForm_1<1088, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-03-26 10:39:02 +08:00
|
|
|
"vsubuhm $vD, $vA, $vB", VecGeneral,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v8i16:$vD, (sub v8i16:$vA, v8i16:$vB))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VSUBUWM : VXForm_1<1152, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-03-26 10:39:02 +08:00
|
|
|
"vsubuwm $vD, $vA, $vB", VecGeneral,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4i32:$vD, (sub v4i32:$vA, v4i32:$vB))]>;
|
2006-03-26 10:39:02 +08:00
|
|
|
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def VSUBSBS : VX1_Int_Ty<1792, "vsubsbs" , int_ppc_altivec_vsubsbs, v16i8>;
|
|
|
|
def VSUBSHS : VX1_Int_Ty<1856, "vsubshs" , int_ppc_altivec_vsubshs, v8i16>;
|
|
|
|
def VSUBSWS : VX1_Int_Ty<1920, "vsubsws" , int_ppc_altivec_vsubsws, v4i32>;
|
|
|
|
def VSUBUBS : VX1_Int_Ty<1536, "vsububs" , int_ppc_altivec_vsububs, v16i8>;
|
|
|
|
def VSUBUHS : VX1_Int_Ty<1600, "vsubuhs" , int_ppc_altivec_vsubuhs, v8i16>;
|
|
|
|
def VSUBUWS : VX1_Int_Ty<1664, "vsubuws" , int_ppc_altivec_vsubuws, v4i32>;
|
|
|
|
|
|
|
|
def VSUMSWS : VX1_Int_Ty<1928, "vsumsws" , int_ppc_altivec_vsumsws, v4i32>;
|
|
|
|
def VSUM2SWS: VX1_Int_Ty<1672, "vsum2sws", int_ppc_altivec_vsum2sws, v4i32>;
|
|
|
|
|
2013-04-26 23:39:57 +08:00
|
|
|
def VSUM4SBS: VX1_Int_Ty3<1800, "vsum4sbs", int_ppc_altivec_vsum4sbs,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
v4i32, v16i8, v4i32>;
|
|
|
|
def VSUM4SHS: VX1_Int_Ty3<1608, "vsum4shs", int_ppc_altivec_vsum4shs,
|
|
|
|
v4i32, v8i16, v4i32>;
|
|
|
|
def VSUM4UBS: VX1_Int_Ty3<1544, "vsum4ubs", int_ppc_altivec_vsum4ubs,
|
|
|
|
v4i32, v16i8, v4i32>;
|
2006-03-28 10:29:37 +08:00
|
|
|
|
2013-04-27 00:53:15 +08:00
|
|
|
def VNOR : VXForm_1<1284, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-03-26 06:16:05 +08:00
|
|
|
"vnor $vD, $vA, $vB", VecFP,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v4i32:$vD, (vnot_ppc (or v4i32:$vA,
|
|
|
|
v4i32:$vB)))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VOR : VXForm_1<1156, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-03-25 15:51:43 +08:00
|
|
|
"vor $vD, $vA, $vB", VecFP,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v4i32:$vD, (or v4i32:$vA, v4i32:$vB))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VXOR : VXForm_1<1220, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-03-25 15:51:43 +08:00
|
|
|
"vxor $vD, $vA, $vB", VecFP,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v4i32:$vD, (xor v4i32:$vA, v4i32:$vB))]>;
|
2006-03-25 15:51:43 +08:00
|
|
|
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def VRLB : VX1_Int_Ty< 4, "vrlb", int_ppc_altivec_vrlb, v16i8>;
|
|
|
|
def VRLH : VX1_Int_Ty< 68, "vrlh", int_ppc_altivec_vrlh, v8i16>;
|
|
|
|
def VRLW : VX1_Int_Ty< 132, "vrlw", int_ppc_altivec_vrlw, v4i32>;
|
2006-04-05 09:16:22 +08:00
|
|
|
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def VSL : VX1_Int_Ty< 452, "vsl" , int_ppc_altivec_vsl, v4i32 >;
|
|
|
|
def VSLO : VX1_Int_Ty<1036, "vslo", int_ppc_altivec_vslo, v4i32>;
|
|
|
|
|
|
|
|
def VSLB : VX1_Int_Ty< 260, "vslb", int_ppc_altivec_vslb, v16i8>;
|
|
|
|
def VSLH : VX1_Int_Ty< 324, "vslh", int_ppc_altivec_vslh, v8i16>;
|
|
|
|
def VSLW : VX1_Int_Ty< 388, "vslw", int_ppc_altivec_vslw, v4i32>;
|
2006-03-28 10:29:37 +08:00
|
|
|
|
2013-04-27 00:53:15 +08:00
|
|
|
def VSPLTB : VXForm_1<524, (outs vrrc:$vD), (ins u5imm:$UIMM, vrrc:$vB),
|
2006-03-25 15:51:43 +08:00
|
|
|
"vspltb $vD, $vB, $UIMM", VecPerm,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v16i8:$vD,
|
|
|
|
(vspltb_shuffle:$UIMM v16i8:$vB, (undef)))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VSPLTH : VXForm_1<588, (outs vrrc:$vD), (ins u5imm:$UIMM, vrrc:$vB),
|
2006-03-25 15:51:43 +08:00
|
|
|
"vsplth $vD, $vB, $UIMM", VecPerm,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v16i8:$vD,
|
|
|
|
(vsplth_shuffle:$UIMM v16i8:$vB, (undef)))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VSPLTW : VXForm_1<652, (outs vrrc:$vD), (ins u5imm:$UIMM, vrrc:$vB),
|
2006-03-25 15:51:43 +08:00
|
|
|
"vspltw $vD, $vB, $UIMM", VecPerm,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v16i8:$vD,
|
|
|
|
(vspltw_shuffle:$UIMM v16i8:$vB, (undef)))]>;
|
2006-03-25 15:51:43 +08:00
|
|
|
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def VSR : VX1_Int_Ty< 708, "vsr" , int_ppc_altivec_vsr, v4i32>;
|
|
|
|
def VSRO : VX1_Int_Ty<1100, "vsro" , int_ppc_altivec_vsro, v4i32>;
|
|
|
|
|
|
|
|
def VSRAB : VX1_Int_Ty< 772, "vsrab", int_ppc_altivec_vsrab, v16i8>;
|
|
|
|
def VSRAH : VX1_Int_Ty< 836, "vsrah", int_ppc_altivec_vsrah, v8i16>;
|
|
|
|
def VSRAW : VX1_Int_Ty< 900, "vsraw", int_ppc_altivec_vsraw, v4i32>;
|
|
|
|
def VSRB : VX1_Int_Ty< 516, "vsrb" , int_ppc_altivec_vsrb , v16i8>;
|
|
|
|
def VSRH : VX1_Int_Ty< 580, "vsrh" , int_ppc_altivec_vsrh , v8i16>;
|
|
|
|
def VSRW : VX1_Int_Ty< 644, "vsrw" , int_ppc_altivec_vsrw , v4i32>;
|
2006-03-28 10:29:37 +08:00
|
|
|
|
|
|
|
|
2013-04-27 00:53:15 +08:00
|
|
|
def VSPLTISB : VXForm_3<780, (outs vrrc:$vD), (ins s5imm:$SIMM),
|
2006-03-27 11:28:57 +08:00
|
|
|
"vspltisb $vD, $SIMM", VecPerm,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v16i8:$vD, (v16i8 vecspltisb:$SIMM))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VSPLTISH : VXForm_3<844, (outs vrrc:$vD), (ins s5imm:$SIMM),
|
2006-03-27 11:28:57 +08:00
|
|
|
"vspltish $vD, $SIMM", VecPerm,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v8i16:$vD, (v8i16 vecspltish:$SIMM))]>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VSPLTISW : VXForm_3<908, (outs vrrc:$vD), (ins s5imm:$SIMM),
|
2006-03-27 11:28:57 +08:00
|
|
|
"vspltisw $vD, $SIMM", VecPerm,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4i32:$vD, (v4i32 vecspltisw:$SIMM))]>;
|
2006-03-25 15:51:43 +08:00
|
|
|
|
2006-03-31 07:07:36 +08:00
|
|
|
// Vector Pack.
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def VPKPX : VX1_Int_Ty2<782, "vpkpx", int_ppc_altivec_vpkpx,
|
|
|
|
v8i16, v4i32>;
|
|
|
|
def VPKSHSS : VX1_Int_Ty2<398, "vpkshss", int_ppc_altivec_vpkshss,
|
|
|
|
v16i8, v8i16>;
|
|
|
|
def VPKSHUS : VX1_Int_Ty2<270, "vpkshus", int_ppc_altivec_vpkshus,
|
|
|
|
v16i8, v8i16>;
|
|
|
|
def VPKSWSS : VX1_Int_Ty2<462, "vpkswss", int_ppc_altivec_vpkswss,
|
|
|
|
v16i8, v4i32>;
|
|
|
|
def VPKSWUS : VX1_Int_Ty2<334, "vpkswus", int_ppc_altivec_vpkswus,
|
|
|
|
v8i16, v4i32>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VPKUHUM : VXForm_1<14, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-03-31 07:07:36 +08:00
|
|
|
"vpkuhum $vD, $vA, $vB", VecFP,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v16i8:$vD,
|
|
|
|
(vpkuhum_shuffle v16i8:$vA, v16i8:$vB))]>;
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def VPKUHUS : VX1_Int_Ty2<142, "vpkuhus", int_ppc_altivec_vpkuhus,
|
|
|
|
v16i8, v8i16>;
|
2013-04-27 00:53:15 +08:00
|
|
|
def VPKUWUM : VXForm_1<78, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2006-03-31 07:07:36 +08:00
|
|
|
"vpkuwum $vD, $vA, $vB", VecFP,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v16i8:$vD,
|
|
|
|
(vpkuwum_shuffle v16i8:$vA, v16i8:$vB))]>;
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def VPKUWUS : VX1_Int_Ty2<206, "vpkuwus", int_ppc_altivec_vpkuwus,
|
|
|
|
v8i16, v4i32>;
|
2006-03-31 07:07:36 +08:00
|
|
|
|
|
|
|
// Vector Unpack.
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def VUPKHPX : VX2_Int_Ty2<846, "vupkhpx", int_ppc_altivec_vupkhpx,
|
|
|
|
v4i32, v8i16>;
|
|
|
|
def VUPKHSB : VX2_Int_Ty2<526, "vupkhsb", int_ppc_altivec_vupkhsb,
|
|
|
|
v8i16, v16i8>;
|
|
|
|
def VUPKHSH : VX2_Int_Ty2<590, "vupkhsh", int_ppc_altivec_vupkhsh,
|
|
|
|
v4i32, v8i16>;
|
|
|
|
def VUPKLPX : VX2_Int_Ty2<974, "vupklpx", int_ppc_altivec_vupklpx,
|
|
|
|
v4i32, v8i16>;
|
|
|
|
def VUPKLSB : VX2_Int_Ty2<654, "vupklsb", int_ppc_altivec_vupklsb,
|
|
|
|
v8i16, v16i8>;
|
|
|
|
def VUPKLSH : VX2_Int_Ty2<718, "vupklsh", int_ppc_altivec_vupklsh,
|
|
|
|
v4i32, v8i16>;
|
2006-03-31 07:07:36 +08:00
|
|
|
|
2006-03-25 15:51:43 +08:00
|
|
|
|
2006-03-26 12:57:17 +08:00
|
|
|
// Altivec Comparisons.
|
|
|
|
|
2006-03-31 13:32:57 +08:00
|
|
|
class VCMP<bits<10> xo, string asmstr, ValueType Ty>
|
2013-04-27 00:53:15 +08:00
|
|
|
: VXRForm_1<xo, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),asmstr,VecFPCompare,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set Ty:$vD, (Ty (PPCvcmp Ty:$vA, Ty:$vB, xo)))]>;
|
2006-03-31 13:32:57 +08:00
|
|
|
class VCMPo<bits<10> xo, string asmstr, ValueType Ty>
|
2013-04-27 00:53:15 +08:00
|
|
|
: VXRForm_1<xo, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),asmstr,VecFPCompare,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set Ty:$vD, (Ty (PPCvcmp_o Ty:$vA, Ty:$vB, xo)))]> {
|
2006-04-05 01:25:31 +08:00
|
|
|
let Defs = [CR6];
|
|
|
|
let RC = 1;
|
|
|
|
}
|
2006-03-31 13:32:57 +08:00
|
|
|
|
|
|
|
// f32 element comparisons.0
|
|
|
|
def VCMPBFP : VCMP <966, "vcmpbfp $vD, $vA, $vB" , v4f32>;
|
|
|
|
def VCMPBFPo : VCMPo<966, "vcmpbfp. $vD, $vA, $vB" , v4f32>;
|
|
|
|
def VCMPEQFP : VCMP <198, "vcmpeqfp $vD, $vA, $vB" , v4f32>;
|
|
|
|
def VCMPEQFPo : VCMPo<198, "vcmpeqfp. $vD, $vA, $vB", v4f32>;
|
|
|
|
def VCMPGEFP : VCMP <454, "vcmpgefp $vD, $vA, $vB" , v4f32>;
|
|
|
|
def VCMPGEFPo : VCMPo<454, "vcmpgefp. $vD, $vA, $vB", v4f32>;
|
|
|
|
def VCMPGTFP : VCMP <710, "vcmpgtfp $vD, $vA, $vB" , v4f32>;
|
|
|
|
def VCMPGTFPo : VCMPo<710, "vcmpgtfp. $vD, $vA, $vB", v4f32>;
|
2006-03-26 12:57:17 +08:00
|
|
|
|
|
|
|
// i8 element comparisons.
|
2006-03-31 13:32:57 +08:00
|
|
|
def VCMPEQUB : VCMP < 6, "vcmpequb $vD, $vA, $vB" , v16i8>;
|
|
|
|
def VCMPEQUBo : VCMPo< 6, "vcmpequb. $vD, $vA, $vB", v16i8>;
|
|
|
|
def VCMPGTSB : VCMP <774, "vcmpgtsb $vD, $vA, $vB" , v16i8>;
|
|
|
|
def VCMPGTSBo : VCMPo<774, "vcmpgtsb. $vD, $vA, $vB", v16i8>;
|
|
|
|
def VCMPGTUB : VCMP <518, "vcmpgtub $vD, $vA, $vB" , v16i8>;
|
|
|
|
def VCMPGTUBo : VCMPo<518, "vcmpgtub. $vD, $vA, $vB", v16i8>;
|
2006-03-26 12:57:17 +08:00
|
|
|
|
|
|
|
// i16 element comparisons.
|
2006-03-31 13:32:57 +08:00
|
|
|
def VCMPEQUH : VCMP < 70, "vcmpequh $vD, $vA, $vB" , v8i16>;
|
|
|
|
def VCMPEQUHo : VCMPo< 70, "vcmpequh. $vD, $vA, $vB", v8i16>;
|
|
|
|
def VCMPGTSH : VCMP <838, "vcmpgtsh $vD, $vA, $vB" , v8i16>;
|
|
|
|
def VCMPGTSHo : VCMPo<838, "vcmpgtsh. $vD, $vA, $vB", v8i16>;
|
|
|
|
def VCMPGTUH : VCMP <582, "vcmpgtuh $vD, $vA, $vB" , v8i16>;
|
|
|
|
def VCMPGTUHo : VCMPo<582, "vcmpgtuh. $vD, $vA, $vB", v8i16>;
|
2006-03-26 12:57:17 +08:00
|
|
|
|
|
|
|
// i32 element comparisons.
|
2006-03-31 13:32:57 +08:00
|
|
|
def VCMPEQUW : VCMP <134, "vcmpequw $vD, $vA, $vB" , v4i32>;
|
|
|
|
def VCMPEQUWo : VCMPo<134, "vcmpequw. $vD, $vA, $vB", v4i32>;
|
|
|
|
def VCMPGTSW : VCMP <902, "vcmpgtsw $vD, $vA, $vB" , v4i32>;
|
|
|
|
def VCMPGTSWo : VCMPo<902, "vcmpgtsw. $vD, $vA, $vB", v4i32>;
|
|
|
|
def VCMPGTUW : VCMP <646, "vcmpgtuw $vD, $vA, $vB" , v4i32>;
|
|
|
|
def VCMPGTUWo : VCMPo<646, "vcmpgtuw. $vD, $vA, $vB", v4i32>;
|
2006-03-26 12:57:17 +08:00
|
|
|
|
2013-07-03 20:51:09 +08:00
|
|
|
let isCodeGenOnly = 1 in {
|
2013-07-12 01:43:32 +08:00
|
|
|
def V_SET0B : VXForm_setzero<1220, (outs vrrc:$vD), (ins),
|
|
|
|
"vxor $vD, $vD, $vD", VecFP,
|
|
|
|
[(set v16i8:$vD, (v16i8 immAllZerosV))]>;
|
|
|
|
def V_SET0H : VXForm_setzero<1220, (outs vrrc:$vD), (ins),
|
|
|
|
"vxor $vD, $vD, $vD", VecFP,
|
|
|
|
[(set v8i16:$vD, (v8i16 immAllZerosV))]>;
|
|
|
|
def V_SET0 : VXForm_setzero<1220, (outs vrrc:$vD), (ins),
|
2006-03-25 15:51:43 +08:00
|
|
|
"vxor $vD, $vD, $vD", VecFP,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v4i32:$vD, (v4i32 immAllZerosV))]>;
|
2013-07-12 01:43:32 +08:00
|
|
|
|
2012-11-30 21:05:44 +08:00
|
|
|
let IMM=-1 in {
|
2013-07-12 01:43:32 +08:00
|
|
|
def V_SETALLONESB : VXForm_3<908, (outs vrrc:$vD), (ins),
|
|
|
|
"vspltisw $vD, -1", VecFP,
|
|
|
|
[(set v16i8:$vD, (v16i8 immAllOnesV))]>;
|
|
|
|
def V_SETALLONESH : VXForm_3<908, (outs vrrc:$vD), (ins),
|
|
|
|
"vspltisw $vD, -1", VecFP,
|
|
|
|
[(set v8i16:$vD, (v8i16 immAllOnesV))]>;
|
|
|
|
def V_SETALLONES : VXForm_3<908, (outs vrrc:$vD), (ins),
|
2012-11-30 21:05:44 +08:00
|
|
|
"vspltisw $vD, -1", VecFP,
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
[(set v4i32:$vD, (v4i32 immAllOnesV))]>;
|
2006-03-25 15:51:43 +08:00
|
|
|
}
|
2013-07-03 20:51:09 +08:00
|
|
|
}
|
2012-11-30 21:05:44 +08:00
|
|
|
} // VALU Operations.
|
2006-03-25 15:51:43 +08:00
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Additional Altivec Patterns
|
|
|
|
//
|
|
|
|
|
2007-09-05 12:05:20 +08:00
|
|
|
// DS* intrinsics
|
2007-08-09 08:49:19 +08:00
|
|
|
def : Pat<(int_ppc_altivec_dssall), (DSSALL 1, 0, 0, 0)>;
|
2007-09-05 12:05:20 +08:00
|
|
|
def : Pat<(int_ppc_altivec_dss imm:$STRM), (DSS 0, imm:$STRM, 0, 0)>;
|
|
|
|
|
|
|
|
// * 32-bit
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def : Pat<(int_ppc_altivec_dst i32:$rA, i32:$rB, imm:$STRM),
|
|
|
|
(DST 0, imm:$STRM, $rA, $rB)>;
|
|
|
|
def : Pat<(int_ppc_altivec_dstt i32:$rA, i32:$rB, imm:$STRM),
|
|
|
|
(DSTT 1, imm:$STRM, $rA, $rB)>;
|
|
|
|
def : Pat<(int_ppc_altivec_dstst i32:$rA, i32:$rB, imm:$STRM),
|
|
|
|
(DSTST 0, imm:$STRM, $rA, $rB)>;
|
|
|
|
def : Pat<(int_ppc_altivec_dststt i32:$rA, i32:$rB, imm:$STRM),
|
|
|
|
(DSTSTT 1, imm:$STRM, $rA, $rB)>;
|
2006-04-06 06:27:14 +08:00
|
|
|
|
2007-09-05 12:05:20 +08:00
|
|
|
// * 64-bit
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def : Pat<(int_ppc_altivec_dst i64:$rA, i32:$rB, imm:$STRM),
|
|
|
|
(DST64 0, imm:$STRM, $rA, $rB)>;
|
|
|
|
def : Pat<(int_ppc_altivec_dstt i64:$rA, i32:$rB, imm:$STRM),
|
|
|
|
(DSTT64 1, imm:$STRM, $rA, $rB)>;
|
|
|
|
def : Pat<(int_ppc_altivec_dstst i64:$rA, i32:$rB, imm:$STRM),
|
|
|
|
(DSTST64 0, imm:$STRM, $rA, $rB)>;
|
|
|
|
def : Pat<(int_ppc_altivec_dststt i64:$rA, i32:$rB, imm:$STRM),
|
|
|
|
(DSTSTT64 1, imm:$STRM, $rA, $rB)>;
|
2007-09-05 12:05:20 +08:00
|
|
|
|
2006-03-25 15:51:43 +08:00
|
|
|
// Loads.
|
2006-06-20 08:39:56 +08:00
|
|
|
def : Pat<(v4i32 (load xoaddr:$src)), (LVX xoaddr:$src)>;
|
2006-03-25 15:51:43 +08:00
|
|
|
|
|
|
|
// Stores.
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def : Pat<(store v4i32:$rS, xoaddr:$dst),
|
|
|
|
(STVX $rS, xoaddr:$dst)>;
|
2006-03-25 15:51:43 +08:00
|
|
|
|
|
|
|
// Bit conversions.
|
|
|
|
def : Pat<(v16i8 (bitconvert (v8i16 VRRC:$src))), (v16i8 VRRC:$src)>;
|
|
|
|
def : Pat<(v16i8 (bitconvert (v4i32 VRRC:$src))), (v16i8 VRRC:$src)>;
|
|
|
|
def : Pat<(v16i8 (bitconvert (v4f32 VRRC:$src))), (v16i8 VRRC:$src)>;
|
|
|
|
|
|
|
|
def : Pat<(v8i16 (bitconvert (v16i8 VRRC:$src))), (v8i16 VRRC:$src)>;
|
|
|
|
def : Pat<(v8i16 (bitconvert (v4i32 VRRC:$src))), (v8i16 VRRC:$src)>;
|
|
|
|
def : Pat<(v8i16 (bitconvert (v4f32 VRRC:$src))), (v8i16 VRRC:$src)>;
|
|
|
|
|
|
|
|
def : Pat<(v4i32 (bitconvert (v16i8 VRRC:$src))), (v4i32 VRRC:$src)>;
|
|
|
|
def : Pat<(v4i32 (bitconvert (v8i16 VRRC:$src))), (v4i32 VRRC:$src)>;
|
|
|
|
def : Pat<(v4i32 (bitconvert (v4f32 VRRC:$src))), (v4i32 VRRC:$src)>;
|
|
|
|
|
|
|
|
def : Pat<(v4f32 (bitconvert (v16i8 VRRC:$src))), (v4f32 VRRC:$src)>;
|
|
|
|
def : Pat<(v4f32 (bitconvert (v8i16 VRRC:$src))), (v4f32 VRRC:$src)>;
|
|
|
|
def : Pat<(v4f32 (bitconvert (v4i32 VRRC:$src))), (v4f32 VRRC:$src)>;
|
|
|
|
|
2006-04-07 02:26:28 +08:00
|
|
|
// Shuffles.
|
|
|
|
|
2006-04-07 06:28:36 +08:00
|
|
|
// Match vsldoi(x,x), vpkuwum(x,x), vpkuhum(x,x)
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def:Pat<(vsldoi_unary_shuffle:$in v16i8:$vA, undef),
|
2013-04-03 22:08:13 +08:00
|
|
|
(VSLDOI $vA, $vA, (VSLDOI_unary_get_imm $in))>;
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def:Pat<(vpkuwum_unary_shuffle v16i8:$vA, undef),
|
|
|
|
(VPKUWUM $vA, $vA)>;
|
|
|
|
def:Pat<(vpkuhum_unary_shuffle v16i8:$vA, undef),
|
|
|
|
(VPKUHUM $vA, $vA)>;
|
2006-04-07 02:26:28 +08:00
|
|
|
|
2006-04-07 06:02:42 +08:00
|
|
|
// Match vmrg*(x,x)
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def:Pat<(vmrglb_unary_shuffle v16i8:$vA, undef),
|
|
|
|
(VMRGLB $vA, $vA)>;
|
|
|
|
def:Pat<(vmrglh_unary_shuffle v16i8:$vA, undef),
|
|
|
|
(VMRGLH $vA, $vA)>;
|
|
|
|
def:Pat<(vmrglw_unary_shuffle v16i8:$vA, undef),
|
|
|
|
(VMRGLW $vA, $vA)>;
|
|
|
|
def:Pat<(vmrghb_unary_shuffle v16i8:$vA, undef),
|
|
|
|
(VMRGHB $vA, $vA)>;
|
|
|
|
def:Pat<(vmrghh_unary_shuffle v16i8:$vA, undef),
|
|
|
|
(VMRGHH $vA, $vA)>;
|
|
|
|
def:Pat<(vmrghw_unary_shuffle v16i8:$vA, undef),
|
|
|
|
(VMRGHW $vA, $vA)>;
|
2006-04-07 06:02:42 +08:00
|
|
|
|
2006-03-26 06:16:05 +08:00
|
|
|
// Logical Operations
|
2013-04-03 22:08:13 +08:00
|
|
|
def : Pat<(vnot_ppc v4i32:$vA), (VNOR $vA, $vA)>;
|
2006-04-16 07:45:24 +08:00
|
|
|
|
2013-04-03 22:08:13 +08:00
|
|
|
def : Pat<(vnot_ppc (or v4i32:$A, v4i32:$B)),
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
(VNOR $A, $B)>;
|
2013-04-03 22:08:13 +08:00
|
|
|
def : Pat<(and v4i32:$A, (vnot_ppc v4i32:$B)),
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
(VANDC $A, $B)>;
|
2006-04-16 07:45:24 +08:00
|
|
|
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def : Pat<(fmul v4f32:$vA, v4f32:$vB),
|
|
|
|
(VMADDFP $vA, $vB,
|
2012-11-30 21:05:44 +08:00
|
|
|
(v4i32 (VSLW (V_SETALLONES), (V_SETALLONES))))>;
|
2006-03-25 15:51:43 +08:00
|
|
|
|
|
|
|
// Fused multiply add and multiply sub for packed float. These are represented
|
|
|
|
// separately from the real instructions above, for operations that must have
|
|
|
|
// the additional precision, such as Newton-Rhapson (used by divide, sqrt)
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def : Pat<(PPCvmaddfp v4f32:$A, v4f32:$B, v4f32:$C),
|
|
|
|
(VMADDFP $A, $B, $C)>;
|
|
|
|
def : Pat<(PPCvnmsubfp v4f32:$A, v4f32:$B, v4f32:$C),
|
|
|
|
(VNMSUBFP $A, $B, $C)>;
|
2006-03-25 15:51:43 +08:00
|
|
|
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def : Pat<(int_ppc_altivec_vmaddfp v4f32:$A, v4f32:$B, v4f32:$C),
|
|
|
|
(VMADDFP $A, $B, $C)>;
|
|
|
|
def : Pat<(int_ppc_altivec_vnmsubfp v4f32:$A, v4f32:$B, v4f32:$C),
|
|
|
|
(VNMSUBFP $A, $B, $C)>;
|
2006-04-05 01:25:31 +08:00
|
|
|
|
2013-04-03 22:08:13 +08:00
|
|
|
def : Pat<(PPCvperm v16i8:$vA, v16i8:$vB, v16i8:$vC),
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
(VPERM $vA, $vB, $vC)>;
|
2009-06-07 09:07:55 +08:00
|
|
|
|
2013-04-03 12:01:11 +08:00
|
|
|
def : Pat<(PPCfre v4f32:$A), (VREFP $A)>;
|
|
|
|
def : Pat<(PPCfrsqrte v4f32:$A), (VRSQRTEFP $A)>;
|
|
|
|
|
2009-06-07 09:07:55 +08:00
|
|
|
// Vector shifts
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def : Pat<(v16i8 (shl v16i8:$vA, v16i8:$vB)),
|
|
|
|
(v16i8 (VSLB $vA, $vB))>;
|
|
|
|
def : Pat<(v8i16 (shl v8i16:$vA, v8i16:$vB)),
|
|
|
|
(v8i16 (VSLH $vA, $vB))>;
|
|
|
|
def : Pat<(v4i32 (shl v4i32:$vA, v4i32:$vB)),
|
|
|
|
(v4i32 (VSLW $vA, $vB))>;
|
|
|
|
|
|
|
|
def : Pat<(v16i8 (srl v16i8:$vA, v16i8:$vB)),
|
|
|
|
(v16i8 (VSRB $vA, $vB))>;
|
|
|
|
def : Pat<(v8i16 (srl v8i16:$vA, v8i16:$vB)),
|
|
|
|
(v8i16 (VSRH $vA, $vB))>;
|
|
|
|
def : Pat<(v4i32 (srl v4i32:$vA, v4i32:$vB)),
|
|
|
|
(v4i32 (VSRW $vA, $vB))>;
|
|
|
|
|
|
|
|
def : Pat<(v16i8 (sra v16i8:$vA, v16i8:$vB)),
|
|
|
|
(v16i8 (VSRAB $vA, $vB))>;
|
|
|
|
def : Pat<(v8i16 (sra v8i16:$vA, v8i16:$vB)),
|
|
|
|
(v8i16 (VSRAH $vA, $vB))>;
|
|
|
|
def : Pat<(v4i32 (sra v4i32:$vA, v4i32:$vB)),
|
|
|
|
(v4i32 (VSRAW $vA, $vB))>;
|
2012-10-09 01:27:24 +08:00
|
|
|
|
|
|
|
// Float to integer and integer to float conversions
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def : Pat<(v4i32 (fp_to_sint v4f32:$vA)),
|
|
|
|
(VCTSXS_0 $vA)>;
|
|
|
|
def : Pat<(v4i32 (fp_to_uint v4f32:$vA)),
|
|
|
|
(VCTUXS_0 $vA)>;
|
|
|
|
def : Pat<(v4f32 (sint_to_fp v4i32:$vA)),
|
|
|
|
(VCFSX_0 $vA)>;
|
|
|
|
def : Pat<(v4f32 (uint_to_fp v4i32:$vA)),
|
|
|
|
(VCFUX_0 $vA)>;
|
2012-11-16 04:56:03 +08:00
|
|
|
|
|
|
|
// Floating-point rounding
|
Use direct types in most PowerPC Altivec instructions and patterns.
This follows up Ulrich Weigand's work in PPCInstrInfo.td and
PPCInstr64Bit.td by doing the corresponding work for most of the
Altivec patterns. I have not been able to do anything for the
following classes of instructions:
(1) Vector logicals. These don't have corresponding intrinsics and
don't have a single obvious vector type. So far as I can tell I need
to leave these as VRRC. Affected instructions are: VAND, VANDC,
VNOR, VOR, VXOR, V_SET0.
(2) Instructions that make use of vector shuffle. The selection code
promotes all shuffles to v16i8, so any pattern that matches on a
shuffle is constrained. I haven't found any way to make the patterns
match on their natural types, so I plan to leave these as VRRC.
Affected instructions are: VMRG*, VSPLTB, VSPLTH, VSPLTW, VPKUHUM,
VPKUWUM.
No change in behavior is anticipated.
llvm-svn: 178277
2013-03-29 03:27:24 +08:00
|
|
|
def : Pat<(v4f32 (ffloor v4f32:$vA)),
|
|
|
|
(VRFIM $vA)>;
|
|
|
|
def : Pat<(v4f32 (fceil v4f32:$vA)),
|
|
|
|
(VRFIP $vA)>;
|
|
|
|
def : Pat<(v4f32 (ftrunc v4f32:$vA)),
|
|
|
|
(VRFIZ $vA)>;
|
|
|
|
def : Pat<(v4f32 (fnearbyint v4f32:$vA)),
|
|
|
|
(VRFIN $vA)>;
|
2013-03-15 21:21:21 +08:00
|
|
|
|
|
|
|
} // end HasAltivec
|
|
|
|
|