[all-commits] [llvm/llvm-project] 92e782: [LV] Choose best reduction for VPlan

[Sander de Smalen via All-commits]

  Branch: refs/heads/users/sdesmalen-arm/lv-partial-reductions-revert-to-regular-reductions
  Home:   https://github.com/llvm/llvm-project
  Commit: 92e7821bbc41b97329047321dc3edd3731d2125a
      https://github.com/llvm/llvm-project/commit/92e7821bbc41b97329047321dc3edd3731d2125a
  Author: Sander de Smalen <sander.desmalen at arm.com>
  Date:   2025-11-03 (Mon, 03 Nov 2025)

  Changed paths:
    M llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
    M llvm/lib/Transforms/Vectorize/VPlan.h
    M llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp
    M llvm/test/Transforms/LoopVectorize/AArch64/partial-reduce-constant-ops.ll
    A llvm/test/Transforms/LoopVectorize/AArch64/partial-reduce-lower-back-to-reguar-reduce.ll
    M llvm/test/Transforms/LoopVectorize/AArch64/partial-reduce.ll

  Log Message:
  -----------
  [LV] Choose best reduction for VPlan

The way partial reductions currently work is as follows:
* Reductions are analysed if they are suitable partial reductions,
  and if so a VPlan is constructed with partial reductions.

* When creating VPExpressions, the LV tries to see if it's beneficial
  to bundle the operation into a VPExpression. If the cost of a partial
  reduction is too high, then the answer is 'no' and it will remain
  unbundled. This means the LV may end up calculating too high a cost
  for a partial reduction VPlan, because it still includes the cost of
  the extends.

* When the cost of a VPlan with partial reductions is higher than the
  plan of a VPlan without partial reductions, it will favour the plan
  without partial reductions. But this is often a plan with a lower VF,
  because partial reductions get the extends for free (and to do this
  for a full vector, it would need a higher VF).

* This means that if the cost of a partial reduction is too high, it
  will pick a lower VF, rather than trying to fall back onto a regular
  reduction (possibly with the same VF).

This PR is a workaround and not the full solution, but there are so
many things to unpick with partial reductions, that I think this is a
good intermediary step before changing how we create partial reduction
vplans.

The better solution would be to wait with the decision on which
style of reduction to choose, based on the cost of the VPExpressions
which also do the analysis to see what kind of expression it is, and
whether the extends can be folded into the operation.

This aims to address the issue reported in #165226



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications