Files
clang-p2996/llvm/test/Transforms/LoopInterchange/call-instructions.ll
Sebastian Pop bf6e1c26cf DA: remove uses of GEP, only ask SCEV
It's been quite some time the Dependence Analysis (DA) is broken,
as it uses the GEP representation to "identify" multi-dimensional arrays.
It even wrongly detects multi-dimensional arrays in single nested loops:

from test/Analysis/DependenceAnalysis/Coupled.ll, example @couple6
;; for (long int i = 0; i < 50; i++) {
;; A[i][3*i - 6] = i;
;; *B++ = A[i][i];

DA used to detect two subscripts, which makes no sense in the LLVM IR
or in C/C++ semantics, as there are no guarantees as in Fortran of
subscripts not overlapping into a next array dimension:

maximum nesting levels = 1
SrcPtrSCEV = %A
DstPtrSCEV = %A
using GEPs
subscript 0
    src = {0,+,1}<nuw><nsw><%for.body>
    dst = {0,+,1}<nuw><nsw><%for.body>
    class = 1
    loops = {1}
subscript 1
    src = {-6,+,3}<nsw><%for.body>
    dst = {0,+,1}<nuw><nsw><%for.body>
    class = 1
    loops = {1}
Separable = {}
Coupled = {1}

With the current patch, DA will correctly work on only one dimension:

maximum nesting levels = 1
SrcSCEV = {(-2424 + %A)<nsw>,+,1212}<%for.body>
DstSCEV = {%A,+,404}<%for.body>
subscript 0
    src = {(-2424 + %A)<nsw>,+,1212}<%for.body>
    dst = {%A,+,404}<%for.body>
    class = 1
    loops = {1}
Separable = {0}
Coupled = {}

This change removes all uses of GEP from DA, and we now only rely
on the SCEV representation.

The patch does not turn on -da-delinearize by default, and so the DA analysis
will be more conservative in the case of multi-dimensional memory accesses in
nested loops.

I disabled some interchange tests, as the DA is not able to disambiguate
the dependence anymore. To make DA stronger, we may need to
compute a bound on the number of iterations based on the access functions
and array dimensions.

The patch cleans up all the CHECKs in test/Transforms/LoopInterchange/*.ll to
avoid checking for snippets of LLVM IR: this form of checking is very hard to
maintain. Instead, we now check for output of the pass that are more meaningful
than dozens of lines of LLVM IR. Some tests now require -debug messages and thus
only enabled with asserts.

Patch written by Sebastian Pop and Aditya Kumar.

Differential Revision: https://reviews.llvm.org/D35430

llvm-svn: 326837
2018-03-06 21:55:59 +00:00

127 lines
3.5 KiB
LLVM

; REQUIRES: asserts
; RUN: opt < %s -basicaa -loop-interchange -verify-dom-info -S -debug 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"
@A = common global [100 x [100 x i32]] zeroinitializer
declare void @foo(i64 %a)
declare void @bar(i64 %a) readnone
;;--------------------------------------Test case 01------------------------------------
;; Not safe to interchange, because the called function `foo` is not marked as
;; readnone, so it could introduce dependences.
;;
;; for(int i=0;i<N;i++) {
;; for(int j=1;j<N;j++) {
;; foo(i);
;; A[j][i] = A[j][i]+k;
;; }
;; }
; CHECK: Not interchanging loops. Cannot prove legality.
define void @interchange_01(i32 %k, i32 %N) {
entry:
%cmp21 = icmp sgt i32 %N, 0
br i1 %cmp21, label %for1.ph, label %exit
for1.ph:
%cmp219 = icmp sgt i32 %N, 1
%0 = add i32 %N, -1
br label %for1.header
for1.header:
%indvars.iv23 = phi i64 [ 0, %for1.ph ], [ %indvars.iv.next24, %for1.inc10 ]
br i1 %cmp219, label %for2.ph, label %for1.inc10
for2.ph:
br label %for2
for2:
%indvars.iv = phi i64 [ %indvars.iv.next, %for2 ], [ 1, %for2.ph ]
call void @foo(i64 %indvars.iv23)
%arrayidx5 = getelementptr inbounds [100 x [100 x i32]], [100 x [100 x i32]]* @A, i64 0, i64 %indvars.iv, i64 %indvars.iv23
%1 = load i32, i32* %arrayidx5
%add = add nsw i32 %1, %k
store i32 %add, i32* %arrayidx5
%indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
%lftr.wideiv = trunc i64 %indvars.iv to i32
%exitcond = icmp eq i32 %lftr.wideiv, %0
br i1 %exitcond, label %for2.loopexit , label %for2
for2.loopexit:
br label %for1.inc10
for1.inc10:
%indvars.iv.next24 = add nuw nsw i64 %indvars.iv23, 1
%lftr.wideiv25 = trunc i64 %indvars.iv23 to i32
%exitcond26 = icmp eq i32 %lftr.wideiv25, %0
br i1 %exitcond26, label %for1.loopexit, label %for1.header
for1.loopexit:
br label %exit
exit:
ret void
}
;;--------------------------------------Test case 02------------------------------------
;; Safe to interchange, because the called function `bar` is marked as readnone,
;; so it cannot introduce dependences.
;;
;; for(int i=0;i<N;i++) {
;; for(int j=1;j<N;j++) {
;; bar(i);
;; A[j][i] = A[j][i]+k;
;; }
;; }
; CHECK: Not interchanging loops. Cannot prove legality.
define void @interchange_02(i32 %k, i32 %N) {
entry:
%cmp21 = icmp sgt i32 %N, 0
br i1 %cmp21, label %for1.ph, label %exit
for1.ph:
%cmp219 = icmp sgt i32 %N, 1
%0 = add i32 %N, -1
br label %for1.header
for1.header:
%indvars.iv23 = phi i64 [ 0, %for1.ph ], [ %indvars.iv.next24, %for1.inc10 ]
br i1 %cmp219, label %for2.ph, label %for1.inc10
for2.ph:
br label %for2
for2:
%indvars.iv = phi i64 [ %indvars.iv.next, %for2 ], [ 1, %for2.ph ]
call void @bar(i64 %indvars.iv23)
%arrayidx5 = getelementptr inbounds [100 x [100 x i32]], [100 x [100 x i32]]* @A, i64 0, i64 %indvars.iv, i64 %indvars.iv23
%1 = load i32, i32* %arrayidx5
%add = add nsw i32 %1, %k
store i32 %add, i32* %arrayidx5
%indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
%lftr.wideiv = trunc i64 %indvars.iv to i32
%exitcond = icmp eq i32 %lftr.wideiv, %0
br i1 %exitcond, label %for2.loopexit , label %for2
for2.loopexit:
br label %for1.inc10
for1.inc10:
%indvars.iv.next24 = add nuw nsw i64 %indvars.iv23, 1
%lftr.wideiv25 = trunc i64 %indvars.iv23 to i32
%exitcond26 = icmp eq i32 %lftr.wideiv25, %0
br i1 %exitcond26, label %for1.loopexit, label %for1.header
for1.loopexit:
br label %exit
exit:
ret void
}