[PATCH] D100121: [LV] Let selectVectorizationFactor reason directly on VectorizationFactor.

[Sander de Smalen via Phabricator via llvm-commits]

sdesmalen created this revision.
Herald added subscribers: bmahjour, hiraditya.
sdesmalen requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

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
is no longer the total cost, but rather the cost per lane which is also
what is used to determine the VF for the vector body loop.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100121

Files:
  llvm/lib/Transforms/Vectorize/LoopVectorizationPlanner.h
  llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
  llvm/test/Transforms/LoopVectorize/X86/avx512.ll
  llvm/test/Transforms/LoopVectorize/X86/intrinsiccost.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D100121.336138.patch
Type: text/x-patch
Size: 11212 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210408/03abc8c3/attachment.bin>