[PATCH] D133580: [VPlan] Only generate single instr for unpredicated stores of varying value to invariant address

Philip Reames via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 12 08:04:05 PDT 2022


reames added inline comments.


================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:9666
+  // A store of a loop varying value to a loop invariant address only
+  // needs a single copy of the store.
+  if (isa<StoreInst>(UI) && !getOperand(1)->getDef()) {
----------------
Ayal wrote:
> @reames , @fhahn - rather than detect individual redundant instances at this late stage to suppress their code-gen, would be better to record such uniformity earlier in VPlan - thereby potentially facilitating the detection of additional redundancies, improving cost estimation, and simplifying code-gen?
Can we not let perfection be the enemy of the good here?  I've tried implementing this a couple of different ways, and this is the one which made it through review.  If you have a different direction you'd like to see, I'm fine making changes in that direction once we have agreement, but I would *strongly* prefer we don't block forward progress on a rework.  

As for your actual suggestion, I would not be opposed to having a true notion of uniformity.  However, it's hard to motivate the complexity beyond uniform loads and stores.  Most uniform computation will have been hoisted by LICM.  You only end up with uniform loads and dependent computations or uniform stores stuck around due to control dependence or aliasing.

I will note that cost model changes have previously been delicate and very tricky to get through review.  So unless you're *strongly* in favor of this direction, I'd really rather not.  


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133580



More information about the llvm-commits mailing list