[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