[PATCH] D19512: [LoopVectorize] Don't consider conditional-load dereferenceability when vectorization is forced
Hal Finkel via llvm-commits
llvm-commits at lists.llvm.org
Mon Apr 25 18:12:16 PDT 2016
hfinkel updated this revision to Diff 54958.
hfinkel added a comment.
It is the llvm.mem.parallel_loop_access that really implies the if-conversion safety. Check that. Note the semantic addition in the LangRef.
http://reviews.llvm.org/D19512
Files:
docs/LangRef.rst
lib/Transforms/Vectorize/LoopVectorize.cpp
test/Transforms/LoopVectorize/X86/force-ifcvt.ll
Index: test/Transforms/LoopVectorize/X86/force-ifcvt.ll
===================================================================
--- /dev/null
+++ test/Transforms/LoopVectorize/X86/force-ifcvt.ll
@@ -0,0 +1,42 @@
+; RUN: opt -loop-vectorize -S < %s | FileCheck %s
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+; Function Attrs: norecurse nounwind uwtable
+define void @Test(i32* nocapture %res, i32* nocapture readnone %c, i32* nocapture readonly %d, i32* nocapture readonly %p) #0 {
+entry:
+ br label %for.body
+
+; CHECK-LABEL: @Test
+; CHECK: <4 x i32>
+
+for.body: ; preds = %cond.end, %entry
+ %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %cond.end ]
+ %arrayidx = getelementptr inbounds i32, i32* %p, i64 %indvars.iv
+ %0 = load i32, i32* %arrayidx, align 4, !llvm.mem.parallel_loop_access !0
+ %cmp1 = icmp eq i32 %0, 0
+ %arrayidx3 = getelementptr inbounds i32, i32* %res, i64 %indvars.iv
+ %1 = load i32, i32* %arrayidx3, align 4, !llvm.mem.parallel_loop_access !0
+ br i1 %cmp1, label %cond.end, label %cond.false
+
+cond.false: ; preds = %for.body
+ %arrayidx7 = getelementptr inbounds i32, i32* %d, i64 %indvars.iv
+ %2 = load i32, i32* %arrayidx7, align 4, !llvm.mem.parallel_loop_access !0
+ %add = add nsw i32 %2, %1
+ br label %cond.end
+
+cond.end: ; preds = %for.body, %cond.false
+ %cond = phi i32 [ %add, %cond.false ], [ %1, %for.body ]
+ store i32 %cond, i32* %arrayidx3, align 4, !llvm.mem.parallel_loop_access !0
+ %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
+ %exitcond = icmp eq i64 %indvars.iv.next, 16
+ br i1 %exitcond, label %for.end, label %for.body, !llvm.loop !0
+
+for.end: ; preds = %cond.end
+ ret void
+}
+
+attributes #0 = { norecurse nounwind uwtable "target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+sse,+sse2,+x87" }
+
+!0 = distinct !{!0, !1}
+!1 = !{!"llvm.loop.vectorize.enable", i1 true}
Index: lib/Transforms/Vectorize/LoopVectorize.cpp
===================================================================
--- lib/Transforms/Vectorize/LoopVectorize.cpp
+++ lib/Transforms/Vectorize/LoopVectorize.cpp
@@ -4873,6 +4873,7 @@
bool LoopVectorizationLegality::blockCanBePredicated(BasicBlock *BB,
SmallPtrSetImpl<Value *> &SafePtrs) {
+ const bool IsAnnotatedParallel = TheLoop->isAnnotatedParallel();
for (BasicBlock::iterator it = BB->begin(), e = BB->end(); it != e; ++it) {
// Check that we don't have a constant expression that can trap as operand.
@@ -4893,6 +4894,9 @@
MaskedOp.insert(LI);
continue;
}
+ // !llvm.mem.parallel_loop_access implies if-conversion safety.
+ if (IsAnnotatedParallel)
+ continue;
return false;
}
}
Index: docs/LangRef.rst
===================================================================
--- docs/LangRef.rst
+++ docs/LangRef.rst
@@ -4716,7 +4716,8 @@
or metadata containing a list of loop identifiers for nested loops.
The metadata is attached to memory accessing instructions and denotes that
no loop carried memory dependence exist between it and other instructions denoted
-with the same loop identifier.
+with the same loop identifier. The metadata on memory reads also implies that
+if conversion (i.e. speculative execution within a loop iteration) is safe.
Precisely, given two instructions ``m1`` and ``m2`` that both have the
``llvm.mem.parallel_loop_access`` metadata, with ``L1`` and ``L2`` being the
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D19512.54958.patch
Type: text/x-patch
Size: 3684 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160426/463c04eb/attachment.bin>
More information about the llvm-commits
mailing list