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), [{
|
2014-08-04 21:53:40 +08:00
|
|
|
return PPC::isVPKUHUMShuffleMask(cast<ShuffleVectorSDNode>(N), 0, *CurDAG);
|
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), [{
|
2014-08-04 21:53:40 +08:00
|
|
|
return PPC::isVPKUWUMShuffleMask(cast<ShuffleVectorSDNode>(N), 0, *CurDAG);
|
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), [{
|
2014-08-04 21:53:40 +08:00
|
|
|
return PPC::isVPKUHUMShuffleMask(cast<ShuffleVectorSDNode>(N), 1, *CurDAG);
|
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), [{
|
2014-08-04 21:53:40 +08:00
|
|
|
return PPC::isVPKUWUMShuffleMask(cast<ShuffleVectorSDNode>(N), 1, *CurDAG);
|
2006-04-07 06:28:36 +08:00
|
|
|
}]>;
|
|
|
|
|
2014-08-04 21:53:40 +08:00
|
|
|
// These fragments are provided for little-endian, where the inputs must be
|
|
|
|
// swapped for correct semantics.
|
|
|
|
def vpkuhum_swapped_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isVPKUHUMShuffleMask(cast<ShuffleVectorSDNode>(N), 2, *CurDAG);
|
|
|
|
}]>;
|
|
|
|
def vpkuwum_swapped_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isVPKUWUMShuffleMask(cast<ShuffleVectorSDNode>(N), 2, *CurDAG);
|
|
|
|
}]>;
|
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), [{
|
2014-07-25 09:55:55 +08:00
|
|
|
return PPC::isVMRGLShuffleMask(cast<ShuffleVectorSDNode>(N), 1, 0, *CurDAG);
|
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), [{
|
2014-07-25 09:55:55 +08:00
|
|
|
return PPC::isVMRGLShuffleMask(cast<ShuffleVectorSDNode>(N), 2, 0, *CurDAG);
|
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), [{
|
2014-07-25 09:55:55 +08:00
|
|
|
return PPC::isVMRGLShuffleMask(cast<ShuffleVectorSDNode>(N), 4, 0, *CurDAG);
|
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), [{
|
2014-07-25 09:55:55 +08:00
|
|
|
return PPC::isVMRGHShuffleMask(cast<ShuffleVectorSDNode>(N), 1, 0, *CurDAG);
|
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), [{
|
2014-07-25 09:55:55 +08:00
|
|
|
return PPC::isVMRGHShuffleMask(cast<ShuffleVectorSDNode>(N), 2, 0, *CurDAG);
|
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), [{
|
2014-07-25 09:55:55 +08:00
|
|
|
return PPC::isVMRGHShuffleMask(cast<ShuffleVectorSDNode>(N), 4, 0, *CurDAG);
|
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), [{
|
2014-07-25 09:55:55 +08:00
|
|
|
return PPC::isVMRGLShuffleMask(cast<ShuffleVectorSDNode>(N), 1, 1, *CurDAG);
|
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), [{
|
2014-07-25 09:55:55 +08:00
|
|
|
return PPC::isVMRGLShuffleMask(cast<ShuffleVectorSDNode>(N), 2, 1, *CurDAG);
|
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), [{
|
2014-07-25 09:55:55 +08:00
|
|
|
return PPC::isVMRGLShuffleMask(cast<ShuffleVectorSDNode>(N), 4, 1, *CurDAG);
|
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), [{
|
2014-07-25 09:55:55 +08:00
|
|
|
return PPC::isVMRGHShuffleMask(cast<ShuffleVectorSDNode>(N), 1, 1, *CurDAG);
|
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), [{
|
2014-07-25 09:55:55 +08:00
|
|
|
return PPC::isVMRGHShuffleMask(cast<ShuffleVectorSDNode>(N), 2, 1, *CurDAG);
|
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), [{
|
2014-07-25 09:55:55 +08:00
|
|
|
return PPC::isVMRGHShuffleMask(cast<ShuffleVectorSDNode>(N), 4, 1, *CurDAG);
|
|
|
|
}]>;
|
|
|
|
|
|
|
|
|
|
|
|
// These fragments are provided for little-endian, where the inputs must be
|
|
|
|
// swapped for correct semantics.
|
|
|
|
def vmrglb_swapped_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle (v16i8 node:$lhs), node:$rhs), [{
|
|
|
|
return PPC::isVMRGLShuffleMask(cast<ShuffleVectorSDNode>(N), 1, 2, *CurDAG);
|
|
|
|
}]>;
|
|
|
|
def vmrglh_swapped_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isVMRGLShuffleMask(cast<ShuffleVectorSDNode>(N), 2, 2, *CurDAG);
|
|
|
|
}]>;
|
|
|
|
def vmrglw_swapped_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isVMRGLShuffleMask(cast<ShuffleVectorSDNode>(N), 4, 2, *CurDAG);
|
|
|
|
}]>;
|
|
|
|
def vmrghb_swapped_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isVMRGHShuffleMask(cast<ShuffleVectorSDNode>(N), 1, 2, *CurDAG);
|
|
|
|
}]>;
|
|
|
|
def vmrghh_swapped_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isVMRGHShuffleMask(cast<ShuffleVectorSDNode>(N), 2, 2, *CurDAG);
|
|
|
|
}]>;
|
|
|
|
def vmrghw_swapped_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isVMRGHShuffleMask(cast<ShuffleVectorSDNode>(N), 4, 2, *CurDAG);
|
2006-04-07 05:11:54 +08:00
|
|
|
}]>;
|
|
|
|
|
2009-04-28 02:41:29 +08:00
|
|
|
|
|
|
|
def VSLDOI_get_imm : SDNodeXForm<vector_shuffle, [{
|
2014-08-06 04:47:25 +08:00
|
|
|
return getI32Imm(PPC::isVSLDOIShuffleMask(N, 0, *CurDAG));
|
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), [{
|
2014-08-06 04:47:25 +08:00
|
|
|
return PPC::isVSLDOIShuffleMask(N, 0, *CurDAG) != -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, [{
|
2014-08-06 04:47:25 +08:00
|
|
|
return getI32Imm(PPC::isVSLDOIShuffleMask(N, 1, *CurDAG));
|
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), [{
|
2014-08-06 04:47:25 +08:00
|
|
|
return PPC::isVSLDOIShuffleMask(N, 1, *CurDAG) != -1;
|
2006-04-07 06:28:36 +08:00
|
|
|
}], VSLDOI_unary_get_imm>;
|
2006-04-07 02:26:28 +08:00
|
|
|
|
|
|
|
|
2014-08-06 04:47:25 +08:00
|
|
|
/// VSLDOI_swapped* - These fragments are provided for little-endian, where
|
|
|
|
/// the inputs must be swapped for correct semantics.
|
|
|
|
def VSLDOI_swapped_get_imm : SDNodeXForm<vector_shuffle, [{
|
|
|
|
return getI32Imm(PPC::isVSLDOIShuffleMask(N, 2, *CurDAG));
|
|
|
|
}]>;
|
|
|
|
def vsldoi_swapped_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
|
|
|
|
(vector_shuffle node:$lhs, node:$rhs), [{
|
|
|
|
return PPC::isVSLDOIShuffleMask(N, 2, *CurDAG) != -1;
|
|
|
|
}], VSLDOI_get_imm>;
|
|
|
|
|
|
|
|
|
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, [{
|
2014-06-10 22:35:01 +08:00
|
|
|
return getI32Imm(PPC::getVSPLTImmediate(N, 1, *CurDAG));
|
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, [{
|
2014-06-10 22:35:01 +08:00
|
|
|
return getI32Imm(PPC::getVSPLTImmediate(N, 2, *CurDAG));
|
2006-04-05 01:25:31 +08:00
|
|
|
}]>;
|
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, [{
|
2014-06-10 22:35:01 +08:00
|
|
|
return getI32Imm(PPC::getVSPLTImmediate(N, 4, *CurDAG));
|
2006-04-05 01:25:31 +08:00
|
|
|
}]>;
|
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),
|
2013-11-28 07:26:09 +08:00
|
|
|
!strconcat(opc, " $vD, $vA, $vB, $vC"), IIC_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 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),
|
2013-11-28 07:26:09 +08:00
|
|
|
!strconcat(opc, " $vD, $vA, $vB, $vC"), IIC_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 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),
|
2013-11-28 07:26:09 +08:00
|
|
|
!strconcat(opc, " $vD, $vA, $vB, $vC"), IIC_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 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),
|
2013-11-28 07:26:09 +08:00
|
|
|
!strconcat(opc, " $vD, $vA, $vB"), IIC_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 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),
|
2013-11-28 07:26:09 +08:00
|
|
|
!strconcat(opc, " $vD, $vA, $vB"), IIC_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 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),
|
2013-11-28 07:26:09 +08:00
|
|
|
!strconcat(opc, " $vD, $vA, $vB"), IIC_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 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),
|
2013-11-28 07:26:09 +08:00
|
|
|
!strconcat(opc, " $vD, $vB"), IIC_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, (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),
|
2013-11-28 07:26:09 +08:00
|
|
|
!strconcat(opc, " $vD, $vB"), IIC_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 OutTy:$vD, (IntID InTy:$vB))]>;
|
|
|
|
|
2006-03-25 15:51:43 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Instruction Definitions.
|
|
|
|
|
2014-05-22 09:07:24 +08:00
|
|
|
def HasAltivec : Predicate<"PPCSubTarget->hasAltivec()">;
|
2013-03-15 21:21:21 +08:00
|
|
|
let Predicates = [HasAltivec] in {
|
|
|
|
|
2014-08-02 23:09:41 +08:00
|
|
|
def DSS : DSS_Form<0, 822, (outs), (ins u5imm:$STRM),
|
|
|
|
"dss $STRM", IIC_LdStLoad /*FIXME*/, [(int_ppc_altivec_dss imm:$STRM)]>,
|
|
|
|
Deprecated<DeprecatedDST> {
|
|
|
|
let A = 0;
|
|
|
|
let B = 0;
|
|
|
|
}
|
2007-09-05 12:05:20 +08:00
|
|
|
|
2014-08-02 23:09:41 +08:00
|
|
|
def DSSALL : DSS_Form<1, 822, (outs), (ins),
|
|
|
|
"dssall", IIC_LdStLoad /*FIXME*/, [(int_ppc_altivec_dssall)]>,
|
|
|
|
Deprecated<DeprecatedDST> {
|
|
|
|
let STRM = 0;
|
|
|
|
let A = 0;
|
|
|
|
let B = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
def DST : DSS_Form<0, 342, (outs), (ins u5imm:$STRM, gprc:$rA, gprc:$rB),
|
|
|
|
"dst $rA, $rB, $STRM", IIC_LdStLoad /*FIXME*/,
|
|
|
|
[(int_ppc_altivec_dst i32:$rA, i32:$rB, imm:$STRM)]>,
|
2013-09-12 22:40:06 +08:00
|
|
|
Deprecated<DeprecatedDST>;
|
2014-08-02 23:09:41 +08:00
|
|
|
|
|
|
|
def DSTT : DSS_Form<1, 342, (outs), (ins u5imm:$STRM, gprc:$rA, gprc:$rB),
|
|
|
|
"dstt $rA, $rB, $STRM", IIC_LdStLoad /*FIXME*/,
|
|
|
|
[(int_ppc_altivec_dstt i32:$rA, i32:$rB, imm:$STRM)]>,
|
2013-09-12 22:40:06 +08:00
|
|
|
Deprecated<DeprecatedDST>;
|
2014-08-02 23:09:41 +08:00
|
|
|
|
|
|
|
def DSTST : DSS_Form<0, 374, (outs), (ins u5imm:$STRM, gprc:$rA, gprc:$rB),
|
|
|
|
"dstst $rA, $rB, $STRM", IIC_LdStLoad /*FIXME*/,
|
|
|
|
[(int_ppc_altivec_dstst i32:$rA, i32:$rB, imm:$STRM)]>,
|
2013-09-12 22:40:06 +08:00
|
|
|
Deprecated<DeprecatedDST>;
|
2014-08-02 23:09:41 +08:00
|
|
|
|
|
|
|
def DSTSTT : DSS_Form<1, 374, (outs), (ins u5imm:$STRM, gprc:$rA, gprc:$rB),
|
|
|
|
"dststt $rA, $rB, $STRM", IIC_LdStLoad /*FIXME*/,
|
|
|
|
[(int_ppc_altivec_dststt i32:$rA, i32:$rB, imm:$STRM)]>,
|
2013-09-12 22:40:06 +08:00
|
|
|
Deprecated<DeprecatedDST>;
|
2014-08-02 23:09:41 +08:00
|
|
|
|
|
|
|
let isCodeGenOnly = 1 in {
|
|
|
|
// The very same instructions as above, but formally matching 64bit registers.
|
|
|
|
def DST64 : DSS_Form<0, 342, (outs), (ins u5imm:$STRM, g8rc:$rA, gprc:$rB),
|
|
|
|
"dst $rA, $rB, $STRM", IIC_LdStLoad /*FIXME*/,
|
|
|
|
[(int_ppc_altivec_dst i64:$rA, i32:$rB, imm:$STRM)]>,
|
|
|
|
Deprecated<DeprecatedDST>;
|
|
|
|
|
|
|
|
def DSTT64 : DSS_Form<1, 342, (outs), (ins u5imm:$STRM, g8rc:$rA, gprc:$rB),
|
|
|
|
"dstt $rA, $rB, $STRM", IIC_LdStLoad /*FIXME*/,
|
|
|
|
[(int_ppc_altivec_dstt i64:$rA, i32:$rB, imm:$STRM)]>,
|
|
|
|
Deprecated<DeprecatedDST>;
|
|
|
|
|
|
|
|
def DSTST64 : DSS_Form<0, 374, (outs), (ins u5imm:$STRM, g8rc:$rA, gprc:$rB),
|
|
|
|
"dstst $rA, $rB, $STRM", IIC_LdStLoad /*FIXME*/,
|
|
|
|
[(int_ppc_altivec_dstst i64:$rA, i32:$rB,
|
|
|
|
imm:$STRM)]>,
|
|
|
|
Deprecated<DeprecatedDST>;
|
|
|
|
|
|
|
|
def DSTSTT64 : DSS_Form<1, 374, (outs), (ins u5imm:$STRM, g8rc:$rA, gprc:$rB),
|
|
|
|
"dststt $rA, $rB, $STRM", IIC_LdStLoad /*FIXME*/,
|
|
|
|
[(int_ppc_altivec_dststt i64:$rA, i32:$rB,
|
|
|
|
imm:$STRM)]>,
|
|
|
|
Deprecated<DeprecatedDST>;
|
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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"mfvscr $vD", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"mtvscr $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"lvebx $vD, $src", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"lvehx $vD, $src", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"lvewx $vD, $src", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"lvx $vD, $src", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"lvxl $vD, $src", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"lvsl $vD, $src", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"lvsr $vD, $src", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"stvebx $rS, $dst", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"stvehx $rS, $dst", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"stvewx $rS, $dst", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"stvx $rS, $dst", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"stvxl $rS, $dst", IIC_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.
|
2014-03-24 23:07:28 +08:00
|
|
|
let isCommutable = 1 in {
|
2013-04-27 00:53:15 +08:00
|
|
|
def VMADDFP : VAForm_1<46, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vC, vrrc:$vB),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vmaddfp $vD, $vA, $vC, $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vnmsubfp $vD, $vA, $vC, $vB", IIC_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,
|
2014-03-24 23:07:28 +08:00
|
|
|
(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>;
|
2014-03-24 23:07:28 +08:00
|
|
|
} // isCommutable
|
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 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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vsldoi $vD, $vA, $vB, $SH", IIC_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.
|
2014-03-24 23:07:28 +08:00
|
|
|
let isCommutable = 1 in {
|
2013-04-27 00:53:15 +08:00
|
|
|
def VADDFP : VXForm_1<10, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vaddfp $vD, $vA, $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vaddubm $vD, $vA, $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vadduhm $vD, $vA, $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vadduwm $vD, $vA, $vB", IIC_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>;
|
2014-03-24 23:07:28 +08:00
|
|
|
} // isCommutable
|
|
|
|
|
|
|
|
let isCommutable = 1 in
|
2013-04-27 00:53:15 +08:00
|
|
|
def VAND : VXForm_1<1028, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vand $vD, $vA, $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vandc $vD, $vA, $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vcfsx $vD, $vB, $UIMM", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vcfux $vD, $vB, $UIMM", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vctsxs $vD, $vB, $UIMM", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vctuxs $vD, $vB, $UIMM", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vcfsx $vD, $vB, 0", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vctuxs $vD, $vB, 0", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vcfux $vD, $vB, 0", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vctsxs $vD, $vB, 0", IIC_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>;
|
|
|
|
|
2014-03-24 23:07:28 +08:00
|
|
|
let isCommutable = 1 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 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>;
|
2014-03-24 23:07:28 +08:00
|
|
|
} // isCommutable
|
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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vmrghb $vD, $vA, $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vmrghh $vD, $vA, $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vmrghw $vD, $vA, $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vmrglb $vD, $vA, $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vmrglh $vD, $vA, $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vmrglw $vD, $vA, $vB", IIC_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>;
|
|
|
|
|
2014-03-24 23:07:28 +08:00
|
|
|
let isCommutable = 1 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 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>;
|
2014-03-24 23:07:28 +08:00
|
|
|
} // isCommutable
|
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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vsubfp $vD, $vA, $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vsububm $vD, $vA, $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vsubuhm $vD, $vA, $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vsubuwm $vD, $vA, $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vnor $vD, $vA, $vB", IIC_VecFP,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v4i32:$vD, (vnot_ppc (or v4i32:$vA,
|
|
|
|
v4i32:$vB)))]>;
|
2014-03-24 23:07:28 +08:00
|
|
|
let isCommutable = 1 in {
|
2013-04-27 00:53:15 +08:00
|
|
|
def VOR : VXForm_1<1156, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vor $vD, $vA, $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vxor $vD, $vA, $vB", IIC_VecFP,
|
2013-04-03 22:08:13 +08:00
|
|
|
[(set v4i32:$vD, (xor v4i32:$vA, v4i32:$vB))]>;
|
2014-03-24 23:07:28 +08:00
|
|
|
} // isCommutable
|
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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vspltb $vD, $vB, $UIMM", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vsplth $vD, $vB, $UIMM", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vspltw $vD, $vB, $UIMM", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vspltisb $vD, $SIMM", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vspltish $vD, $SIMM", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vspltisw $vD, $SIMM", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vpkuhum $vD, $vA, $vB", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vpkuwum $vD, $vA, $vB", IIC_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-11-28 07:26:09 +08:00
|
|
|
: VXRForm_1<xo, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB), asmstr,
|
|
|
|
IIC_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-11-28 07:26:09 +08:00
|
|
|
: VXRForm_1<xo, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB), asmstr,
|
|
|
|
IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vxor $vD, $vD, $vD", IIC_VecFP,
|
2013-07-12 01:43:32 +08:00
|
|
|
[(set v16i8:$vD, (v16i8 immAllZerosV))]>;
|
|
|
|
def V_SET0H : VXForm_setzero<1220, (outs vrrc:$vD), (ins),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vxor $vD, $vD, $vD", IIC_VecFP,
|
2013-07-12 01:43:32 +08:00
|
|
|
[(set v8i16:$vD, (v8i16 immAllZerosV))]>;
|
|
|
|
def V_SET0 : VXForm_setzero<1220, (outs vrrc:$vD), (ins),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vxor $vD, $vD, $vD", IIC_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),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vspltisw $vD, -1", IIC_VecFP,
|
2013-07-12 01:43:32 +08:00
|
|
|
[(set v16i8:$vD, (v16i8 immAllOnesV))]>;
|
|
|
|
def V_SETALLONESH : VXForm_3<908, (outs vrrc:$vD), (ins),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vspltisw $vD, -1", IIC_VecFP,
|
2013-07-12 01:43:32 +08:00
|
|
|
[(set v8i16:$vD, (v8i16 immAllOnesV))]>;
|
|
|
|
def V_SETALLONES : VXForm_3<908, (outs vrrc:$vD), (ins),
|
2013-11-28 07:26:09 +08:00
|
|
|
"vspltisw $vD, -1", IIC_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
|
|
|
|
//
|
|
|
|
|
|
|
|
// 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)>;
|
2015-02-04 05:58:23 +08:00
|
|
|
def : Pat<(v16i8 (bitconvert (v2i64 VRRC:$src))), (v16i8 VRRC:$src)>;
|
2006-03-25 15:51:43 +08:00
|
|
|
|
|
|
|
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)>;
|
2015-02-04 05:58:23 +08:00
|
|
|
def : Pat<(v8i16 (bitconvert (v2i64 VRRC:$src))), (v8i16 VRRC:$src)>;
|
2006-03-25 15:51:43 +08:00
|
|
|
|
|
|
|
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)>;
|
2015-02-04 05:58:23 +08:00
|
|
|
def : Pat<(v4i32 (bitconvert (v2i64 VRRC:$src))), (v4i32 VRRC:$src)>;
|
2006-03-25 15:51:43 +08:00
|
|
|
|
|
|
|
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)>;
|
2015-02-04 05:58:23 +08:00
|
|
|
def : Pat<(v4f32 (bitconvert (v2i64 VRRC:$src))), (v4f32 VRRC:$src)>;
|
|
|
|
|
|
|
|
def : Pat<(v2i64 (bitconvert (v16i8 VRRC:$src))), (v2i64 VRRC:$src)>;
|
|
|
|
def : Pat<(v2i64 (bitconvert (v8i16 VRRC:$src))), (v2i64 VRRC:$src)>;
|
|
|
|
def : Pat<(v2i64 (bitconvert (v4i32 VRRC:$src))), (v2i64 VRRC:$src)>;
|
|
|
|
def : Pat<(v2i64 (bitconvert (v4f32 VRRC:$src))), (v2i64 VRRC:$src)>;
|
2006-03-25 15:51:43 +08:00
|
|
|
|
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
|
|
|
|
2014-08-06 04:47:25 +08:00
|
|
|
// Match vsldoi(y,x), vpkuwum(y,x), vpkuhum(y,x), i.e., swapped operands.
|
|
|
|
// These fragments are matched for little-endian, where the inputs must
|
|
|
|
// be swapped for correct semantics.
|
|
|
|
def:Pat<(vsldoi_swapped_shuffle:$in v16i8:$vA, v16i8:$vB),
|
|
|
|
(VSLDOI $vB, $vA, (VSLDOI_swapped_get_imm $in))>;
|
2014-08-04 21:53:40 +08:00
|
|
|
def:Pat<(vpkuwum_swapped_shuffle v16i8:$vA, v16i8:$vB),
|
|
|
|
(VPKUWUM $vB, $vA)>;
|
|
|
|
def:Pat<(vpkuhum_swapped_shuffle v16i8:$vA, v16i8:$vB),
|
|
|
|
(VPKUHUM $vB, $vA)>;
|
|
|
|
|
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
|
|
|
|
2014-07-25 09:55:55 +08:00
|
|
|
// Match vmrg*(y,x), i.e., swapped operands. These fragments
|
|
|
|
// are matched for little-endian, where the inputs must be
|
|
|
|
// swapped for correct semantics.
|
|
|
|
def:Pat<(vmrglb_swapped_shuffle v16i8:$vA, v16i8:$vB),
|
|
|
|
(VMRGLB $vB, $vA)>;
|
|
|
|
def:Pat<(vmrglh_swapped_shuffle v16i8:$vA, v16i8:$vB),
|
|
|
|
(VMRGLH $vB, $vA)>;
|
|
|
|
def:Pat<(vmrglw_swapped_shuffle v16i8:$vA, v16i8:$vB),
|
|
|
|
(VMRGLW $vB, $vA)>;
|
|
|
|
def:Pat<(vmrghb_swapped_shuffle v16i8:$vA, v16i8:$vB),
|
|
|
|
(VMRGHB $vB, $vA)>;
|
|
|
|
def:Pat<(vmrghh_swapped_shuffle v16i8:$vA, v16i8:$vB),
|
|
|
|
(VMRGHH $vB, $vA)>;
|
|
|
|
def:Pat<(vmrghw_swapped_shuffle v16i8:$vA, v16i8:$vB),
|
|
|
|
(VMRGHW $vB, $vA)>;
|
|
|
|
|
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
|
|
|
|
|
2015-02-04 05:58:23 +08:00
|
|
|
def HasP8Altivec : Predicate<"PPCSubTarget->hasP8Altivec()">;
|
|
|
|
let Predicates = [HasP8Altivec] in {
|
2015-02-05 23:24:47 +08:00
|
|
|
|
|
|
|
// Count Leading Zeros
|
|
|
|
def VCLZB : VXForm_2<1794, (outs vrrc:$vD), (ins vrrc:$vB),
|
|
|
|
"vclzb $vD, $vB", IIC_VecGeneral,
|
|
|
|
[(set v16i8:$vD, (ctlz v16i8:$vB))]>;
|
|
|
|
def VCLZH : VXForm_2<1858, (outs vrrc:$vD), (ins vrrc:$vB),
|
|
|
|
"vclzh $vD, $vB", IIC_VecGeneral,
|
|
|
|
[(set v8i16:$vD, (ctlz v8i16:$vB))]>;
|
|
|
|
def VCLZW : VXForm_2<1922, (outs vrrc:$vD), (ins vrrc:$vB),
|
|
|
|
"vclzw $vD, $vB", IIC_VecGeneral,
|
|
|
|
[(set v4i32:$vD, (ctlz v4i32:$vB))]>;
|
|
|
|
def VCLZD : VXForm_2<1986, (outs vrrc:$vD), (ins vrrc:$vB),
|
|
|
|
"vclzd $vD, $vB", IIC_VecGeneral,
|
|
|
|
[(set v2i64:$vD, (ctlz v2i64:$vB))]>;
|
|
|
|
|
2015-02-04 05:58:23 +08:00
|
|
|
// Population Count
|
|
|
|
def VPOPCNTB : VXForm_2<1795, (outs vrrc:$vD), (ins vrrc:$vB),
|
|
|
|
"vpopcntb $vD, $vB", IIC_VecGeneral,
|
|
|
|
[(set v16i8:$vD, (ctpop v16i8:$vB))]>;
|
|
|
|
def VPOPCNTH : VXForm_2<1859, (outs vrrc:$vD), (ins vrrc:$vB),
|
|
|
|
"vpopcnth $vD, $vB", IIC_VecGeneral,
|
|
|
|
[(set v8i16:$vD, (ctpop v8i16:$vB))]>;
|
|
|
|
def VPOPCNTW : VXForm_2<1923, (outs vrrc:$vD), (ins vrrc:$vB),
|
|
|
|
"vpopcntw $vD, $vB", IIC_VecGeneral,
|
|
|
|
[(set v4i32:$vD, (ctpop v4i32:$vB))]>;
|
|
|
|
def VPOPCNTD : VXForm_2<1987, (outs vrrc:$vD), (ins vrrc:$vB),
|
|
|
|
"vpopcntd $vD, $vB", IIC_VecGeneral,
|
|
|
|
[(set v2i64:$vD, (ctpop v2i64:$vB))]>;
|
2015-02-10 01:03:18 +08:00
|
|
|
|
|
|
|
let isCommutable = 1 in {
|
|
|
|
// FIXME: Use AddedComplexity > 400 to ensure these patterns match before the
|
|
|
|
// VSX equivalents. We need to fix this up at some point. Two possible
|
|
|
|
// solutions for this problem:
|
|
|
|
// 1. Disable Altivec patterns that compete with VSX patterns using the
|
|
|
|
// !HasVSX predicate. This essentially favours VSX over Altivec, in
|
|
|
|
// hopes of reducing register pressure (larger register set using VSX
|
|
|
|
// instructions than VMX instructions)
|
|
|
|
// 2. Employ a more disciplined use of AddedComplexity, which would provide
|
|
|
|
// more fine-grained control than option 1. This would be beneficial
|
|
|
|
// if we find situations where Altivec is really preferred over VSX.
|
|
|
|
def VEQV : VXForm_1<1668, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
|
|
|
"veqv $vD, $vA, $vB", IIC_VecGeneral,
|
|
|
|
[(set v4i32:$vD, (vnot_ppc (xor v4i32:$vA, v4i32:$vB)))]>;
|
|
|
|
def VNAND : VXForm_1<1412, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
|
|
|
"vnand $vD, $vA, $vB", IIC_VecGeneral,
|
|
|
|
[(set v4i32:$vD, (vnot_ppc (and v4i32:$vA, v4i32:$vB)))]>;
|
|
|
|
def VORC : VXForm_1<1348, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
|
|
|
|
"vorc $vD, $vA, $vB", IIC_VecGeneral,
|
|
|
|
[(set v4i32:$vD, (or v4i32:$vA,
|
|
|
|
(vnot_ppc v4i32:$vB)))]>;
|
|
|
|
} // isCommutable
|
2015-02-04 05:58:23 +08:00
|
|
|
} // end HasP8Altivec
|