[llvm] [VPlan] Factor out logic to common compute costs to helper (NFCI). (PR #153361)
David Sherwood via llvm-commits
llvm-commits at lists.llvm.org
Thu Aug 14 02:01:22 PDT 2025
================
@@ -940,28 +940,88 @@ Value *VPInstruction::generate(VPTransformState &State) {
}
}
+std::optional<InstructionCost>
+VPRecipeWithIRFlags::getCommonCost(unsigned Opcode, ElementCount VF,
+ VPCostContext &Ctx, bool IsVector) const {
+ Type *ScalarTy = Ctx.Types.inferScalarType(this);
+ Type *ResultTy = IsVector ? toVectorTy(ScalarTy, VF) : ScalarTy;
+ switch (Opcode) {
+ case Instruction::FNeg:
+ return Ctx.TTI.getArithmeticInstrCost(
+ Opcode, ResultTy, Ctx.CostKind,
+ {TargetTransformInfo::OK_AnyValue, TargetTransformInfo::OP_None},
+ {TargetTransformInfo::OK_AnyValue, TargetTransformInfo::OP_None});
+ case Instruction::UDiv:
+ case Instruction::SDiv:
+ case Instruction::SRem:
+ case Instruction::URem:
+ case Instruction::Add:
+ case Instruction::FAdd:
+ case Instruction::Sub:
+ case Instruction::FSub:
+ case Instruction::Mul:
+ case Instruction::FMul:
+ case Instruction::FDiv:
+ case Instruction::FRem:
+ case Instruction::Shl:
+ case Instruction::LShr:
+ case Instruction::AShr:
+ case Instruction::And:
+ case Instruction::Or:
+ case Instruction::Xor: {
+ VPValue *RHS = getOperand(1);
+ // Certain instructions can be cheaper to vectorize if they have a constant
+ // second vector operand. One example of this are shifts on x86.
+ TargetTransformInfo::OperandValueInfo RHSInfo = Ctx.getOperandInfo(RHS);
+
+ if (RHSInfo.Kind == TargetTransformInfo::OK_AnyValue &&
+ getOperand(1)->isDefinedOutsideLoopRegions())
+ RHSInfo.Kind = TargetTransformInfo::OK_UniformValue;
+ Instruction *CtxI = dyn_cast_or_null<Instruction>(getUnderlyingValue());
+
+ SmallVector<const Value *, 4> Operands;
+ if (CtxI)
+ Operands.append(CtxI->value_op_begin(), CtxI->value_op_end());
+ return Ctx.TTI.getArithmeticInstrCost(
+ Opcode, ResultTy, Ctx.CostKind,
+ {TargetTransformInfo::OK_AnyValue, TargetTransformInfo::OP_None},
+ RHSInfo, Operands, CtxI, &Ctx.TLI);
+ }
+ case Instruction::Freeze:
+ // This opcode is unknown. Assume that it is the same as 'mul'.
+ return Ctx.TTI.getArithmeticInstrCost(Instruction::Mul, ResultTy,
+ Ctx.CostKind);
+ case Instruction::ExtractValue:
+ return Ctx.TTI.getInsertExtractValueCost(Instruction::ExtractValue,
+ Ctx.CostKind);
+ case Instruction::ICmp:
+ case Instruction::FCmp: {
+ Type *ScalarOpTy = Ctx.Types.inferScalarType(getOperand(0));
+ Type *OpTy = IsVector ? toVectorTy(ScalarOpTy, VF) : ScalarOpTy;
+ Instruction *CtxI = dyn_cast_or_null<Instruction>(getUnderlyingValue());
+ return Ctx.TTI.getCmpSelInstrCost(
+ Opcode, OpTy, CmpInst::makeCmpResultType(OpTy), getPredicate(),
----------------
david-arm wrote:
Shouldn't we assert that result type matches the actual result type in vplan? I don't know if there is anything in vplan that fundamentally restricts icmp/fcmp to be consistent with `CmpInst::makeCmpResultType(OpTy)`
https://github.com/llvm/llvm-project/pull/153361
More information about the llvm-commits
mailing list