[llvm] [AArch64][CostModel] Consider i32 --> i64 partial reduce cost as Invalid for FixedLength vectors (PR #165226)
Sander de Smalen via llvm-commits
llvm-commits at lists.llvm.org
Thu Oct 30 04:19:17 PDT 2025
================
@@ -5757,8 +5757,15 @@ InstructionCost AArch64TTIImpl::getPartialReductionCost(
return Cost;
}
+ if (!ST->useSVEForFixedLengthVectors() &&
----------------
sdesmalen-arm wrote:
I think it's worth adding a comment here to describe why we do this, along with a FIXME to suggest this is a workaround.
The way things currently work is as follows:
* The LV decides early on whether or not to use partial reductions based 'getPartialReductionCost`. If the cost is invalid, the plan does not consider the use of partial reductions (and it will consider this plan to use 'regular' reductions instead).
* Later on the LV costs all plans to determine the best one. If the cost of a partial reduction vplan is too high, it will not be chosen.
This means that if you don't want the LV to choose a VPlan with partial reductions for the given types, because we prefer the use of regular reductions for that loop, then the cost-model should return `Invalid`.
If we want to use partial reductions for these types, and prefer it over other partial reductions, then we should return a valid (but lower) cost.
The comment I would suggest would be something like:
```
// Prefer to use regular reductions because of throughput of smlalb/t instructions.
// FIXME: We should actually be returning a higher cost instead of Invalid, but this
// requires fixing the way the LV handles partial reductions.
```
The more structural way to address the FIXME would be to stop making this decision early on and instead decide if partial reductions are favoured over regular reductions, so that we compare the "best reduction plan" for the given VF to the "best reduction plan" for another VF. Whereas now it compares a partial reduction plan for the given VF to another (partial/non-partial) reduction plan for another VF. This is something we're planning to fix, but it requires some bigger changes to how the LV handles partial reductions.
https://github.com/llvm/llvm-project/pull/165226
More information about the llvm-commits
mailing list