[PATCH] D54538: [LV] Avoid vectorizing unsafe dependencies in uniform address

Anna Thomas via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 19 07:17:56 PST 2018


anna marked 5 inline comments as done.
anna added inline comments.


================
Comment at: include/llvm/Analysis/LoopAccessAnalysis.h:569
+  /// dependency with a uniform load, then return true, else return false.
+  bool hasNonVectorizableStoresToLoopInvariantAddress() const {
+    return HasNonVectorizableStoresToLoopInvariantAddress;
----------------
Ayal wrote:
> Can simply state that if there's a memory dependence involving an invariant address, i.e., two stores or a store and a load, return true, else return false.
> 
> Could alternatively name it `hasDependenceInvolvingLoopInvariantAddress`
> 
> Note that a load from an invariant address that depends on store(s) to it in the loop, should ideally be promoted to use the temporary being stored; the temporary value gets expanded, unlike the store to the invariant address. The missed ORE message could indicate such potential resolution.
addressed first 2 comments. Regarding the third one, the entirety of stores to invariant address or store-followed-by-load to inv address is a missed optimization not handled before vectorization, i.e. scalar promotion and LICM. 


================
Comment at: test/Transforms/LoopVectorize/invariant-store-vectorization.ll:568
+  %tmp9 = phi i32 [ %arg1, %bb ], [ %tmp23, %bb7 ]
+  %tmp10 = load i32, i32* %tmp
+  %tmp11 = mul nsw i32 %tmp9, %tmp10
----------------
Ayal wrote:
> (Note: load could be replaced by phi(%arg4, %tmp12), a potentially vectorizable 1st-order-recurrence.)
good point! I'll add that as a comment.


Repository:
  rL LLVM

https://reviews.llvm.org/D54538





More information about the llvm-commits mailing list