[all-commits] [llvm/llvm-project] f15666: [SLP] Inefficient cost-modelling and codegen for r...

[Sushant Gokhale via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f15666db52ffafe798d9247442cb941c9dffd5b5
      https://github.com/llvm/llvm-project/commit/f15666db52ffafe798d9247442cb941c9dffd5b5
  Author: Sushant Gokhale <sgokhale at nvidia.com>
  Date:   2026-06-10 (Wed, 10 Jun 2026)

  Changed paths:
    M llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
    M llvm/test/Transforms/SLPVectorizer/SystemZ/revec-fix-128169.ll
    M llvm/test/Transforms/SLPVectorizer/X86/revec-reduced-value-vectorized-later.ll
    M llvm/test/Transforms/SLPVectorizer/revec.ll

  Log Message:
  -----------
  [SLP] Inefficient cost-modelling and codegen for reductions with slp-… (#197875)

…revec

When revectorizing, starting with reduction, SLP generates slightly
inefficient code for reduction. e.g. In the godbolt link
[here](https://godbolt.org/z/ez7KPnxM5),
`hor_reduction --> original code`
`hor_reduction_revec_as_imagined_in_SLP --> revectorized code would look
like`

Rather than extracting per lane, we can extract original leaf nodes of
the reduction, which are sub-vectors, and then perform usual reduction
as in non-revectorized code. In the above link,
`hor_reduction_ideal_revec --> how the revec code should look like`

Extracting subvectors and achieving the reduction result would be better
than extracting per lane and achieving the same result.



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