================
@@ -3589,6 +3596,42 @@
tryToMatchAndCreateMulAccumulateReduction(VPReductionRecipe *Red,
Sub = VecOp->getDefiningRecipe();
VecOp = Tmp;
}
+
+ // If ValB is a constant and can be safely extended, truncate it to the same
+ // type as ExtA's operand, then extend it to the same type as ExtA. This
+ // creates two uniform extends that can more easily be matched by the rest of
+ // the bundling code. The ExtB reference, ValB and operand 1 of Mul are all
+ // replaced with the new extend of the constant.
+ auto ExtendAndReplaceConstantOp = [&Ctx](VPWidenCastRecipe *ExtA,
+ VPWidenCastRecipe *&ExtB,
+ VPValue *&ValB, VPWidenRecipe *Mul)
{
+ if (ExtA && !ExtB && ValB->isLiveIn()) {
+ Type *NarrowTy = Ctx.Types.inferScalarType(ExtA->getOperand(0));
+ Type *WideTy = Ctx.Types.inferScalarType(ExtA);
+ Instruction::CastOps ExtOpc = ExtA->getOpcode();
+ auto *Const = dyn_cast<ConstantInt>(ValB->getLiveInIRValue());
+ if (Const &&
+ llvm::canConstantBeExtended(
+ Const, NarrowTy, TTI::getPartialReductionExtendKind(ExtOpc))) {
+ // The truncate ensures that the type of each extended operand is the
+ // same, and it's been proven that the constant can be extended from
+ // NarrowTy safely. Necessary since ExtA's extended operand would be
+ // e.g. an i8, while the const will likely be an i32. This will be
+ // elided by later optimisations.
----------------
sdesmalen-arm wrote:
> Could we avoid introcuding the explicit cast recipe by just creating a new
> extended live-in?
Is there any particular downside to creating the explicit cast recipe? (I'm
asking in case handling this in pattern matching and VPExpression recipes would
be tricky for some reason)
> There currently are quite a bit of changes in the diff that make it a bit
> difficult to see how that directly relates to supporting constants
FWIW, a lot of the changes in this PR currently are unrelated to supporting
constants, so I've asked those to be removed from this PR
(https://github.com/llvm/llvm-project/pull/162503#discussion_r2454676680 and
https://github.com/llvm/llvm-project/pull/162503#discussion_r2454677805)
https://github.com/llvm/llvm-project/pull/162503
_______________________________________________
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
