[PATCH] D155804: [LV] Cache call vectorization decisions

Graham Hunter via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 20 02:06:46 PDT 2023


huntergr created this revision.
huntergr added reviewers: fhahn, david-arm.
Herald added subscribers: artagnon, mgabka, StephenFan, hiraditya.
Herald added a project: All.
huntergr requested review of this revision.
Herald added subscribers: llvm-commits, wangpc.
Herald added a project: LLVM.

LoopVectorize currently queries VFDatabase repeatedly for each CI, and each query to VFDatabase rescans all vector variants.

I think it would be better to find any available variants once for each VF and then cache that decision, similarly to how loads and stores are handled.

I've kept them in a separate map for this initial patch, but it may be worthwhile to unify the maps.

While doing this I had to move calls to collectInLoopReductions to ensure that the information was always available before making the decision, and discovered that a unit test for guarding the cost of strict fadd operations had been broken for a while -- the costs had been changed to those of a normal fmuladd intrinsic, not an in-order vector reduction, at least at the point the initial cost was calculated and displayed by LoopVectorize.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D155804

Files:
  llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
  llvm/test/Transforms/LoopVectorize/AArch64/strict-fadd-cost.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D155804.542377.patch
Type: text/x-patch
Size: 22790 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230720/8ec94212/attachment.bin>


More information about the llvm-commits mailing list