[polly] record delinearization result and reuse it in polyhedral translation
Tobias Grosser
tobias at grosser.es
Tue Jun 3 10:48:02 PDT 2014
On 03/06/2014 18:22, Sebastian Pop wrote:
> Tobias Grosser wrote:
>> >This looks good in general, but it would be good to explain_why_ we
>> >are doing this and to provide a test case that shows that this is
>> >necessary.
> In the polyhedral translation there are two ways to delinearize together all
> array subscripts touching the same base address: either duplicate the code from
> scop detection to first gather all array references and then run the
> delinearization; or the solution that I implemented and that we discussed at one
> of the polly phone callsthat is to use the same delinearization info that we
> computed during scop detection.
Right. I am aware what this patch is doing. My comment was mainly for
the commit message.
> I added a testcase that checks that we delinearize together all the subscripts,
> otherwise we would end on a different representation. Please see attached an
> updated patch. Ok to commit?
That's what I meant. LGTM.
> From d84497278df8f41aebe2a79fff4715735ee648e8 Mon Sep 17 00:00:00 2001
> From: Sebastian Pop<spop at codeaurora.org>
> Date: Fri, 30 May 2014 17:12:18 -0500
> Subject: [PATCH] record delinearization result and reuse it in polyhedral
> translation
>
> there are two ways to delinearize together all array subscripts touching the
> same base address: either duplicate the code from scop detection to first gather
> all array references and then run the delinearization; or as implemented in this
> patch, use the same delinearization info that we computed during scop detection.
>
> Without this patch, the testcase would correctly find the delinearization of the
> first array, and would fail on the delinearization of the second array: it is
> possible to find a good the delinearization for A[i][0][k] only in the context
^^^ grammar.
I think the point above is the main motivation of the patch. Putting it
at the beginning of the commit message may make it even more understandable.
> of both array accesses.
>
> ; void foo(long n, long m, long o, double A[n][m][o]) {
> ; for (long i = 0; i < n; i++)
> ; for (long j = 0; j < m; j++)
> ; for (long k = 0; k < o; k++) {
> ; A[i+3][j-4][k+7] = 1.0;
> ; A[i][0][k] = 2.0;
> ; }
> ; }
>
> ; CHECK: [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[3 + i0, -4 + i1, 7 + i2] };
> ; CHECK: [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[i0, 0, i2] };
>
> Here is the output of FileCheck on the testcase without this patch:
>
> ; CHECK: [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[i0, 0, i2] };
> ^
> <stdin>:26:2: note: possible intended match here
> [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[o0] };
This was exactly the example I was looking for. Putting it also in the
commit message case is a good idea.
Cheers,
Tobias
More information about the llvm-commits
mailing list