[all-commits] [llvm/llvm-project] 867295: [LV] Let selectVectorizationFactor reason directly...

[sdesmalen-arm via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 86729538bdbdbacae8855e80da488173ac8a8250
      https://github.com/llvm/llvm-project/commit/86729538bdbdbacae8855e80da488173ac8a8250
  Author: Sander de Smalen <sander.desmalen at arm.com>
  Date:   2021-04-20 (Tue, 20 Apr 2021)

  Changed paths:
    M llvm/lib/Transforms/Vectorize/LoopVectorizationPlanner.h
    M llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
    M llvm/lib/Transforms/Vectorize/VPlan.h
    M llvm/test/Transforms/LoopVectorize/X86/avx512.ll
    M llvm/test/Transforms/LoopVectorize/X86/intrinsiccost.ll

  Log Message:
  -----------
  [LV] Let selectVectorizationFactor reason directly on VectorizationFactor.

Rather than maintaining two separate values, a `float` for the per-lane
cost and a Width for the VF, maintain a single VectorizationFactor which
comprises the two and also removes the need for converting an integer value
to float.

This simplifies the query when asking if one VF is more profitable than
another when we want to extend this for scalable vectors (which may
require additional options to determine if e.g. a scalable VF of the
some cost, is more profitable than a fixed VF of the same cost).

The patch isn't entirely NFC because it also fixes an issue in
selectEpilogueVectorizationFactor, where the cost passed to ProfitableVFs
no longer truncates the floating-point cost from `float` to `unsigned` to
then perform the calculation on the truncated cost. It now does
a cost comparison with the correct precision.

Reviewed By: dmgreen

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