[all-commits] [llvm/llvm-project] 9803b0: [RISCV] Implement getVScaleForTuning and thus pref...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9803b0d1e7b3cbcce33c1c91d4e1cd1f20eea3d4
      https://github.com/llvm/llvm-project/commit/9803b0d1e7b3cbcce33c1c91d4e1cd1f20eea3d4
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2022-06-25 (Sat, 25 Jun 2022)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVTargetTransformInfo.cpp
    M llvm/lib/Target/RISCV/RISCVTargetTransformInfo.h
    M llvm/test/Transforms/LoopVectorize/RISCV/scalable-basics.ll

  Log Message:
  -----------
  [RISCV] Implement getVScaleForTuning and thus prefer scalable vectorization when enabled

LoopVectorizer uses getVScaleForTuning for deciding how to discount the cost of a potential vector factor by the amount of work performed. Without the callback implemented, the vectorizer was defaulting to an estimated vscale of 1. This results in fixed vectorization looking falsely profitable (since it used the command line VLEN).

The test change is pretty limited since a) we don't have much coverage of the vectorizer with scalable vectors at all, and b) what little coverage we have mostly uses i64 element types. There's a separate issue with <vscale x 1 x i64> which prevents us from getting to this stage of costing, and thus only the one test explicitly written to avoid that is visible in the diff. However, this is actually a very wide impact change as it changes the practical vectorization result when both fixed and scalable is enabled to scalable.

As an aside, I think the vectorizer is at little too strongly biased towards scalable when both are legal, but we can explore that separately. For now, let's just get the cost model working the way it was intended.

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