llvm-6502/test/Analysis/LoopAccessAnalysis/underlying-objects-1.ll
Adam Nemet 50b9e7f7d4 [getUnderlyingOjbects] Analyze loop PHIs further to remove false positives
Specifically, if a pointer accesses different underlying objects in each
iteration, don't look through the phi node defining the pointer.

The motivating case is the underlyling-objects-2.ll testcase.  Consider
the loop nest:

  int **A;
  for (i)
    for (j)
       A[i][j] = A[i-1][j] * B[j]

This loop is transformed by Load-PRE to stash away A[i] for the next
iteration of the outer loop:

  Curr = A[0];          // Prev_0
  for (i: 1..N) {
    Prev = Curr;        // Prev = PHI (Prev_0, Curr)
    Curr = A[i];
    for (j: 0..N)
       Curr[j] = Prev[j] * B[j]
  }

Since A[i] and A[i-1] are likely to be independent pointers,
getUnderlyingObjects should not assume that Curr and Prev share the same
underlying object in the inner loop.

If it did we would try to dependence-analyze Curr and Prev and the
analysis of the corresponding SCEVs would fail with non-constant
distance.

To fix this, the getUnderlyingObjects API is extended with an optional
LoopInfo parameter.  This is effectively what controls whether we want
the above behavior or the original.  Currently, I only changed to use
this approach for LoopAccessAnalysis.

The other testcase is to guard the opposite case where we do want to
look through the loop PHI.  If we step through an array by incrementing
a pointer, the underlying object is the incoming value of the phi as the
loop is entered.

Fixes rdar://problem/19566729

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235634 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-23 20:09:20 +00:00

48 lines
1.4 KiB
LLVM

; RUN: opt -basicaa -loop-accesses -analyze < %s | FileCheck %s
; In:
;
; store_ptr = A;
; load_ptr = &A[2];
; for (i = 0; i < n; i++)
; *store_ptr++ = *load_ptr++ *10; // A[i] = A[i+2] * 10
;
; make sure, we look through the PHI to conclude that store_ptr and load_ptr
; both have A as their underlying object. The dependence is safe for
; vectorization requiring no memchecks.
;
; Otherwise we would try to prove independence with a memcheck that is going
; to always fail.
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.10.0"
; CHECK: Memory dependences are safe{{$}}
define void @f(i8* noalias %A, i64 %width) {
for.body.preheader:
%A_ahead = getelementptr inbounds i8, i8* %A, i64 2
br label %for.body
for.body:
%i = phi i64 [ %i.1, %for.body ], [ 0, %for.body.preheader ]
%load_ptr = phi i8* [ %load_ptr.1, %for.body ], [ %A_ahead, %for.body.preheader ]
%store_ptr = phi i8* [ %store_ptr.1, %for.body ], [ %A, %for.body.preheader ]
%loadA = load i8, i8* %load_ptr, align 1
%mul = mul i8 %loadA, 10
store i8 %mul, i8* %store_ptr, align 1
%load_ptr.1 = getelementptr inbounds i8, i8* %load_ptr, i64 1
%store_ptr.1 = getelementptr inbounds i8, i8* %store_ptr, i64 1
%i.1 = add nuw i64 %i, 1
%exitcond = icmp eq i64 %i.1, %width
br i1 %exitcond, label %for.end, label %for.body
for.end:
ret void
}