[llvm] [SystemZ] Fix Operand Retrieval for Vector Reduction Intrinsic in `shouldExpandReduction` (PR #88874)
Jonas Paulsson via llvm-commits
llvm-commits at lists.llvm.org
Thu Apr 18 04:36:46 PDT 2024
================
@@ -1323,25 +1324,43 @@ SystemZTTIImpl::getIntrinsicInstrCost(const IntrinsicCostAttributes &ICA,
}
bool SystemZTTIImpl::shouldExpandReduction(const IntrinsicInst *II) const {
- // Always expand on Subtargets without vector instructions
+ // Always expand on Subtargets without vector instructions.
if (!ST->hasVector())
return true;
- // Always expand for operands that do not fill one vector reg
- auto *Type = cast<FixedVectorType>(II->getOperand(0)->getType());
- unsigned NumElts = Type->getNumElements();
- unsigned ScalarSize = Type->getScalarSizeInBits();
+ // Find the type of the vector operand of the intrinsic
+ // This assumes that each vector reduction intrinsic only
+ // has one vector operand.
+ FixedVectorType *VType = 0x0;
+ for (unsigned I = 0; I < II->getNumOperands(); ++I) {
+ auto *T = II->getOperand(I)->getType();
+ if (T->isVectorTy()) {
+ VType = cast<FixedVectorType>(T);
+ break;
+ }
+ }
+
+ // If we did not find a vector operand, do not continue.
+ if (VType == 0x0)
+ return true;
+
+ // If the vector operand is not a full vector, the reduction
+ // should be expanded.
+ unsigned NumElts = VType->getNumElements();
+ unsigned ScalarSize = VType->getScalarSizeInBits();
unsigned MaxElts = SystemZ::VectorBits / ScalarSize;
if (NumElts < MaxElts)
return true;
- // Otherwise
+ // Handling of full vector operands depends on the
+ // individual intrinsic.
switch (II->getIntrinsicID()) {
- // Do not expand vector.reduce.add
- case Intrinsic::vector_reduce_add:
- // Except for i64, since the performance benefit is dubious there
- return ScalarSize >= 64;
default:
return true;
+ // Do not expand vector.reduce.add...
+ case Intrinsic::vector_reduce_add:
----------------
JonPsson1 wrote:
This style of commenting is kind of nice but I find it perhaps a little unusual compared to https://llvm.org/docs/CodingStandards.html#id8. I guess it's up to you how you want to write it, but at the very least add the final period. I think typically the comment for a particular switch case should be in one place, probably all just below the 'case' line.
https://github.com/llvm/llvm-project/pull/88874
More information about the llvm-commits
mailing list