[all-commits] [llvm/llvm-project] 7f26c2: [RISCV] Enable SLP by default (when vectors are av...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7f26c27e03f1b6b12a3450627934ee26256649cd
      https://github.com/llvm/llvm-project/commit/7f26c27e03f1b6b12a3450627934ee26256649cd
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2023-06-14 (Wed, 14 Jun 2023)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVTargetTransformInfo.cpp
    M llvm/test/Transforms/SLPVectorizer/RISCV/floating-point.ll
    M llvm/test/Transforms/SLPVectorizer/RISCV/load-binop-store.ll
    M llvm/test/Transforms/SLPVectorizer/RISCV/load-store.ll
    M llvm/test/Transforms/SLPVectorizer/RISCV/math-function.ll

  Log Message:
  -----------
  [RISCV] Enable SLP by default (when vectors are available)

I propose that we go ahead and enabled SLP by default. Over the last few weeks, @luke and I have been working through codegen issues seen at small VLs from a couple of SPEC workloads. We still have a ways to go to get optimal codegen, but we're at the point where having a single configuration we're all tuning against is probably the right default.

As a bit of history, I introduced this TTI hook back in a310637132 back in August of last year to unblock enabling LoopVectorizer. At the time, we had a couple known issues: constant materialization, address generation, and a general lack of maturity of small fixed vector codegen. By now, each of these has had significant investment. I can't say any of them are completely fixed, but we're no longer seeing instances of them every place we look.

What we're mostly seeing at this point is a long tail of code gen opportunities, many involving build vectors, shuffles, and extract patterns. I have a couple patches up to continue iterating on those issues, but I don't think they need to be blockers for enabling SLP.

Differential Revision: https://reviews.llvm.org/D152750