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-07 05:55:59 +08:00
|
|
|
; REQUIRES: asserts
|
2018-04-05 17:48:45 +08:00
|
|
|
; RUN: opt < %s -basicaa -loop-interchange -verify-dom-info -verify-loop-info \
|
|
|
|
|
; RUN: -S -debug 2>&1 | FileCheck %s
|
2017-07-18 17:47:06 +08:00
|
|
|
|
|
|
|
|
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
|
|
|
|
|
@B = common global [100 x i32] zeroinitializer
|
|
|
|
|
@C = common global [100 x [100 x i32]] zeroinitializer
|
|
|
|
|
@D = common global [100 x [100 x [100 x i32]]] zeroinitializer
|
|
|
|
|
|
|
|
|
|
;; Test that a flow dependency in outer loop doesn't prevent interchange in
|
|
|
|
|
;; loops i and j.
|
|
|
|
|
;;
|
|
|
|
|
;; for (int k = 0; k < 100; ++k) {
|
|
|
|
|
;; T[k] = fn1();
|
|
|
|
|
;; for (int i = 0; i < 1000; ++i)
|
|
|
|
|
;; for(int j = 1; j < 1000; ++j)
|
|
|
|
|
;; Arr[j][i] = Arr[j][i]+k;
|
|
|
|
|
;; fn2(T[k]);
|
|
|
|
|
;; }
|
|
|
|
|
|
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-07 05:55:59 +08:00
|
|
|
; CHECK: Processing Inner Loop Id = 2 and OuterLoopId = 1
|
|
|
|
|
; CHECK: Loops interchanged.
|
|
|
|
|
|
|
|
|
|
; CHECK: Processing Inner Loop Id = 1 and OuterLoopId = 0
|
|
|
|
|
; CHECK: Not interchanging loops. Cannot prove legality.
|
|
|
|
|
|
2017-07-18 17:47:06 +08:00
|
|
|
@T = internal global [100 x double] zeroinitializer, align 4
|
|
|
|
|
@Arr = internal global [1000 x [1000 x i32]] zeroinitializer, align 4
|
|
|
|
|
|
|
|
|
|
define void @interchange_09(i32 %k) {
|
|
|
|
|
entry:
|
|
|
|
|
br label %for.body
|
|
|
|
|
|
|
|
|
|
for.cond.cleanup: ; preds = %for.cond.cleanup4
|
|
|
|
|
ret void
|
|
|
|
|
|
|
|
|
|
for.body: ; preds = %for.cond.cleanup4, %entry
|
|
|
|
|
%indvars.iv45 = phi i64 [ 0, %entry ], [ %indvars.iv.next46, %for.cond.cleanup4 ]
|
|
|
|
|
%call = call double @fn1()
|
|
|
|
|
%arrayidx = getelementptr inbounds [100 x double], [100 x double]* @T, i64 0, i64 %indvars.iv45
|
|
|
|
|
store double %call, double* %arrayidx, align 8
|
|
|
|
|
br label %for.cond6.preheader
|
|
|
|
|
|
|
|
|
|
for.cond6.preheader: ; preds = %for.cond.cleanup8, %for.body
|
|
|
|
|
%indvars.iv42 = phi i64 [ 0, %for.body ], [ %indvars.iv.next43, %for.cond.cleanup8 ]
|
|
|
|
|
br label %for.body9
|
|
|
|
|
|
|
|
|
|
for.cond.cleanup4: ; preds = %for.cond.cleanup8
|
|
|
|
|
%tmp = load double, double* %arrayidx, align 8
|
|
|
|
|
call void @fn2(double %tmp)
|
|
|
|
|
%indvars.iv.next46 = add nuw nsw i64 %indvars.iv45, 1
|
|
|
|
|
%exitcond47 = icmp ne i64 %indvars.iv.next46, 100
|
|
|
|
|
br i1 %exitcond47, label %for.body, label %for.cond.cleanup
|
|
|
|
|
|
|
|
|
|
for.cond.cleanup8: ; preds = %for.body9
|
|
|
|
|
%indvars.iv.next43 = add nuw nsw i64 %indvars.iv42, 1
|
|
|
|
|
%exitcond44 = icmp ne i64 %indvars.iv.next43, 1000
|
|
|
|
|
br i1 %exitcond44, label %for.cond6.preheader, label %for.cond.cleanup4
|
|
|
|
|
|
|
|
|
|
for.body9: ; preds = %for.body9, %for.cond6.preheader
|
|
|
|
|
%indvars.iv = phi i64 [ 1, %for.cond6.preheader ], [ %indvars.iv.next, %for.body9 ]
|
|
|
|
|
%arrayidx13 = getelementptr inbounds [1000 x [1000 x i32]], [1000 x [1000 x i32]]* @Arr, i64 0, i64 %indvars.iv, i64 %indvars.iv42
|
|
|
|
|
%tmp1 = load i32, i32* %arrayidx13, align 4
|
|
|
|
|
%tmp2 = trunc i64 %indvars.iv45 to i32
|
|
|
|
|
%add = add nsw i32 %tmp1, %tmp2
|
|
|
|
|
store i32 %add, i32* %arrayidx13, align 4
|
|
|
|
|
%indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
|
|
|
|
|
%exitcond = icmp ne i64 %indvars.iv.next, 1000
|
|
|
|
|
br i1 %exitcond, label %for.body9, label %for.cond.cleanup8
|
|
|
|
|
}
|
|
|
|
|
|
[LoopInterchange] Do not interchange loops with function calls.
Summary:
Without any information about the called function, we cannot be sure
that it is safe to interchange loops which contain function calls. For
example there could be dependences that prevent interchanging between
accesses in the called function and the loops. Even functions without any
parameters could cause problems, as they could access memory using
global pointers.
For now, I think it is only safe to interchange loops with calls marked
as readnone.
With this patch, the LLVM test suite passes with `-O3 -mllvm
-enable-loopinterchange` and LoopInterchangeProfitability::isProfitable
returning true for all loops. check-llvm and check-clang also pass when
bootstrapped in a similar fashion, although only 3 loops got
interchanged.
Reviewers: karthikthecool, blitz.opensource, hfinkel, mcrosier, mkuper
Reviewed By: mcrosier
Subscribers: mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D35489
llvm-svn: 309547
2017-07-31 17:00:52 +08:00
|
|
|
declare double @fn1() readnone
|
|
|
|
|
declare void @fn2(double) readnone
|