[PATCH] D96522: [LV] Try larger VFs if VF is unprofitable for small types.

[Florian Hahn via Phabricator via llvm-commits]

fhahn updated this revision to Diff 407245.
fhahn marked 2 inline comments as done.
fhahn added a comment.
Herald added a subscriber: ctetreau.

A blast from the past :)

Rebased and updated to work with scalable VFs as well.

In D96522#2559177 <https://reviews.llvm.org/D96522#2559177>, @dmgreen wrote:

> OK, More about the loads being expensive than the reductions. If this is for 4 x i8 loads being expensive, should we just be overriding shouldMaximizeVectorBandwidth on AArch64? It could be based on SmallestType / WidestType if that makes it more precise, but I don't know that it needs to be.
> https://godbolt.org/z/xG55W6
>
> That would prevent us from putting this into the vectorizer costmodel directly, which may not be correct with the made up alignments/address space, and no indication of whether the loads are extended or not.

The extended loads case is interesting. To catch that, we effectively would have to look at all the loads. Where we do that wouldn't matter too much I think.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96522/new/

https://reviews.llvm.org/D96522

Files:
  llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
  llvm/test/Transforms/LoopVectorize/AArch64/extend-vectorization-factor-for-unprofitable-memops.ll
  llvm/test/Transforms/LoopVectorize/AArch64/scalable-vectorization-cost-tuning.ll
  llvm/test/Transforms/LoopVectorize/AArch64/scalable-vectorization.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D96522.407245.patch
Type: text/x-patch
Size: 6574 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220209/282fb6ff/attachment.bin>