forked from OSchip/llvm-project
1 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
Andreas Simbuerger
|
e478e2de83 |
[Polly][WIP] Scalar fully indexed expansion
Summary: This patch comes directly after https://reviews.llvm.org/D34982 which allows fully indexed expansion of MemoryKind::Array. This patch allows expansion for MemoryKind::Value and MemoryKind::PHI. MemoryKind::Value seems to be working with no majors modifications of D34982. A test case has been added. Unfortunatly, no "run time" checks can be done for now because as @Meinersbur explains in a comment on D34982, DependenceInfo need to be cleared and reset to take expansion into account in the remaining part of the Polly pipeline. There is no way to do that in Polly for now. MemoryKind::PHI is not working. Test case is in place, but not working. To expand MemoryKind::Array, we expand first the write and then after the reads. For MemoryKind::PHI, the idea of the current implementation is to exchange the "roles" of the read and write and expand first the read according to its domain and after the writes. But with this strategy, I still encounter the problem of union_map in new access map. For example with the following source code (source code of the test case) : ``` void mse(double A[Ni], double B[Nj]) { int i,j; double tmp = 6; for (i = 0; i < Ni; i++) { for (int j = 0; j<Nj; j++) { tmp = tmp + 2; } B[i] = tmp; } } ``` Polly gives us the following statements and memory accesses : ``` Statements { Stmt_for_body Domain := { Stmt_for_body[i0] : 0 <= i0 <= 9999 }; Schedule := { Stmt_for_body[i0] -> [i0, 0, 0] }; ReadAccess := [Reduction Type: NONE] [Scalar: 1] { Stmt_for_body[i0] -> MemRef_tmp_04__phi[] }; MustWriteAccess := [Reduction Type: NONE] [Scalar: 1] { Stmt_for_body[i0] -> MemRef_tmp_11__phi[] }; Instructions { %tmp.04 = phi double [ 6.000000e+00, %entry.split ], [ %add.lcssa, %for.end ] } Stmt_for_inc Domain := { Stmt_for_inc[i0, i1] : 0 <= i0 <= 9999 and 0 <= i1 <= 9999 }; Schedule := { Stmt_for_inc[i0, i1] -> [i0, 1, i1] }; MustWriteAccess := [Reduction Type: NONE] [Scalar: 1] { Stmt_for_inc[i0, i1] -> MemRef_tmp_11__phi[] }; ReadAccess := [Reduction Type: NONE] [Scalar: 1] { Stmt_for_inc[i0, i1] -> MemRef_tmp_11__phi[] }; MustWriteAccess := [Reduction Type: NONE] [Scalar: 1] { Stmt_for_inc[i0, i1] -> MemRef_add_lcssa__phi[] }; Instructions { %tmp.11 = phi double [ %tmp.04, %for.body ], [ %add, %for.inc ] %add = fadd double %tmp.11, 2.000000e+00 %exitcond = icmp ne i32 %inc, 10000 } Stmt_for_end Domain := { Stmt_for_end[i0] : 0 <= i0 <= 9999 }; Schedule := { Stmt_for_end[i0] -> [i0, 2, 0] }; MustWriteAccess := [Reduction Type: NONE] [Scalar: 1] { Stmt_for_end[i0] -> MemRef_tmp_04__phi[] }; ReadAccess := [Reduction Type: NONE] [Scalar: 1] { Stmt_for_end[i0] -> MemRef_add_lcssa__phi[] }; MustWriteAccess := [Reduction Type: NONE] [Scalar: 0] { Stmt_for_end[i0] -> MemRef_B[i0] }; Instructions { %add.lcssa = phi double [ %add, %for.inc ] store double %add.lcssa, double* %arrayidx, align 8 %exitcond5 = icmp ne i64 %indvars.iv.next, 10000 } } ``` and the following dependences : ``` { Stmt_for_inc[i0, 9999] -> Stmt_for_end[i0] : 0 <= i0 <= 9999; Stmt_for_inc[i0, i1] -> Stmt_for_inc[i0, 1 + i1] : 0 <= i0 <= 9999 and 0 <= i1 <= 9998; Stmt_for_body[i0] -> Stmt_for_inc[i0, 0] : 0 <= i0 <= 9999; Stmt_for_end[i0] -> Stmt_for_body[1 + i0] : 0 <= i0 <= 9998 } ``` When trying to expand this memory access : ``` { Stmt_for_inc[i0, i1] -> MemRef_tmp_11__phi[] }; ``` The new access map would look like this : ``` { Stmt_for_inc[i0, 9999] -> MemRef_tmp_11__phi_exp[i0] : 0 <= i0 <= 9999; Stmt_for_inc[i0, i1] ->MemRef_tmp_11__phi_exp[i0, 1 + i1] : 0 <= i0 <= 9999 and 0 <= i1 <= 9998 } ``` The idea to implement the expansion for PHI access is an idea from @Meinersbur and I don't understand why my implementation does not work. I should have miss something in the understanding of the idea. Contributed by: Nicolas Bonfante <nicolas.bonfante@gmail.com> Reviewers: Meinersbur, simbuerg, bollu Reviewed By: Meinersbur Subscribers: llvm-commits, pollydev, Meinersbur Differential Revision: https://reviews.llvm.org/D36647 llvm-svn: 311619 |