From: Hans Wennborg Date: Thu, 19 Jan 2017 18:35:20 +0000 (+0000) Subject: Merging r292254 and r292280: X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=ae77d22f6bb1e707f698b582e287b7998971a5aa;p=llvm Merging r292254 and r292280: ------------------------------------------------------------------------ r292254 | mssimpso | 2017-01-17 12:51:39 -0800 (Tue, 17 Jan 2017) | 8 lines [LV] Mark non-consecutive-like pointers non-uniform If a memory instruction will be vectorized, but it's pointer operand is non-consecutive-like, the instruction is a gather or scatter operation. Its pointer operand will be non-uniform. This should fix PR31671. Reference: https://llvm.org/bugs/show_bug.cgi?id=31671 Differential Revision: https://reviews.llvm.org/D28819 ------------------------------------------------------------------------ ------------------------------------------------------------------------ r292280 | mssimpso | 2017-01-17 14:21:33 -0800 (Tue, 17 Jan 2017) | 1 line [LV] Add requires asserts to test case ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292503 91177308-0d34-0410-b5e6-96231b3b80d8 --- diff --git a/lib/Transforms/Vectorize/LoopVectorize.cpp b/lib/Transforms/Vectorize/LoopVectorize.cpp index 1b1f86f8efd..dac7032fa08 100644 --- a/lib/Transforms/Vectorize/LoopVectorize.cpp +++ b/lib/Transforms/Vectorize/LoopVectorize.cpp @@ -5602,6 +5602,13 @@ void LoopVectorizationLegality::collectLoopUniforms() { // is consecutive-like, the pointer operand should remain uniform. else if (hasConsecutiveLikePtrOperand(&I)) ConsecutiveLikePtrs.insert(Ptr); + + // Otherwise, if the memory instruction will be vectorized and its + // pointer operand is non-consecutive-like, the memory instruction should + // be a gather or scatter operation. Its pointer operand will be + // non-uniform. + else + PossibleNonUniformPtrs.insert(Ptr); } // Add to the Worklist all consecutive and consecutive-like pointers that diff --git a/test/Transforms/LoopVectorize/X86/consecutive-ptr-uniforms.ll b/test/Transforms/LoopVectorize/X86/consecutive-ptr-uniforms.ll new file mode 100644 index 00000000000..32bfcd2275a --- /dev/null +++ b/test/Transforms/LoopVectorize/X86/consecutive-ptr-uniforms.ll @@ -0,0 +1,56 @@ +; REQUIRES: asserts +; RUN: opt < %s -loop-vectorize -instcombine -S -debug-only=loop-vectorize -disable-output -print-after=instcombine 2>&1 | FileCheck %s + +target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" +target triple = "x86_64-unknown-linux-gnu" + +; CHECK-LABEL: PR31671 +; +; Check a pointer in which one of its uses is consecutive-like and another of +; its uses is non-consecutive-like. In the test case below, %tmp3 is the +; pointer operand of an interleaved load, making it consecutive-like. However, +; it is also the pointer operand of a non-interleaved store that will become a +; scatter operation. %tmp3 (and the induction variable) should not be marked +; uniform-after-vectorization. +; +; CHECK: LV: Found uniform instruction: %tmp0 = getelementptr inbounds %data, %data* %d, i64 0, i32 3, i64 %i +; CHECK-NOT: LV: Found uniform instruction: %tmp3 = getelementptr inbounds %data, %data* %d, i64 0, i32 0, i64 %i +; CHECK-NOT: LV: Found uniform instruction: %i = phi i64 [ %i.next, %for.body ], [ 0, %entry ] +; CHECK-NOT: LV: Found uniform instruction: %i.next = add nuw nsw i64 %i, 5 +; CHECK: vector.body: +; CHECK: %vec.ind = phi <16 x i64> +; CHECK: %[[T0:.+]] = extractelement <16 x i64> %vec.ind, i32 0 +; CHECK: %[[T1:.+]] = getelementptr inbounds %data, %data* %d, i64 0, i32 3, i64 %[[T0]] +; CHECK: %[[T2:.+]] = bitcast float* %[[T1]] to <80 x float>* +; CHECK: load <80 x float>, <80 x float>* %[[T2]], align 4 +; CHECK: %[[T3:.+]] = getelementptr inbounds %data, %data* %d, i64 0, i32 0, i64 %[[T0]] +; CHECK: %[[T4:.+]] = bitcast float* %[[T3]] to <80 x float>* +; CHECK: load <80 x float>, <80 x float>* %[[T4]], align 4 +; CHECK: %VectorGep = getelementptr inbounds %data, %data* %d, i64 0, i32 0, <16 x i64> %vec.ind +; CHECK: call void @llvm.masked.scatter.v16f32({{.*}}, <16 x float*> %VectorGep, {{.*}}) +; CHECK: br i1 {{.*}}, label %middle.block, label %vector.body + +%data = type { [32000 x float], [3 x i32], [4 x i8], [32000 x float] } + +define void @PR31671(float %x, %data* %d) #0 { +entry: + br label %for.body + +for.body: + %i = phi i64 [ %i.next, %for.body ], [ 0, %entry ] + %tmp0 = getelementptr inbounds %data, %data* %d, i64 0, i32 3, i64 %i + %tmp1 = load float, float* %tmp0, align 4 + %tmp2 = fmul float %x, %tmp1 + %tmp3 = getelementptr inbounds %data, %data* %d, i64 0, i32 0, i64 %i + %tmp4 = load float, float* %tmp3, align 4 + %tmp5 = fadd float %tmp4, %tmp2 + store float %tmp5, float* %tmp3, align 4 + %i.next = add nuw nsw i64 %i, 5 + %cond = icmp slt i64 %i.next, 32000 + br i1 %cond, label %for.body, label %for.end + +for.end: + ret void +} + +attributes #0 = { "target-cpu"="knl" }