This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [GRAPHITE] Re: Loop Transformations Question
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Cristianno Martins <cristiannomartins at gmail dot com>
- Cc: "Lista Gcc/Graphite" <gcc-graphite at googlegroups dot com>, "Lista Gcc/Graphite" <gcc at gcc dot gnu dot org>
- Date: Tue, 9 Feb 2010 18:17:40 +0100
- Subject: Re: [GRAPHITE] Re: Loop Transformations Question
- References: <7bf670d1002071331y147036a9l805e97fc72c99a36@mail.gmail.com> <7bf670d1002090901x541a2894h6f15c051e5cf4950@mail.gmail.com>
On Tue, Feb 9, 2010 at 6:01 PM, Cristianno Martins
<cristiannomartins@gmail.com> wrote:
> Hi everyone,
>
> First of all, I already find [and fix] the problem that I had
> described in the last email.
> Now, I need a help with a pretty intriguing issue, described below.
>
> Well, such as I told in the last email, I'm working on a
> implementation of a heuristic for loop skewing transformation. To
> expose the issue, I will show how it happens with an example.
>
> First, the code used to compile is very simple, and can be seen below
> (the matrix dimensions were minimized for simplification).
> <code>
> ?#define m 20
> ?#define n 30
> ?int a[m][n];
> ?int main() {
> ? ? int i, j;
> ? ? for(i = 0; i < m; i++)
> ? ? ? ?for(j = 0; j < n; j++)
> ? ? ? ? ? a[i][j] = 1;
>
> ? ? return a[1][1] + a[2][2];
> ?}
> </code>
>
> After the skewing pass, if I call
>
> <code>
> ?cloog_prog_clast pc = scop_to_clast (scop);
> ?printf ("\nCLAST generated by CLooG: \n");
> ?print_clast_stmt (stdout, pc.stmt);
> </code>
>
> I get the following result:
>
> <terminal>
> ?CLAST generated by CLooG:
> ?for (scat_1=0;scat_1<=48;scat_1++) {
> ? ? for (scat_3=max(scat_1-29,0);scat_3<=min(scat_1,19);scat_3++) {
> ? ? ? ?b[scat_3][scat_1-scat_3] = 1 ;
> ? ? }
> ?}
> <terminal>
>
> Going ahead with this, such as can be seen in
> simple_test.c.105t.graphite [attached], the code is correctly
> generated (in gimple), but the important bb is:
>
> <file>
> ?<bb 3>:
> ? ? ?# graphite_IV.5_17 = PHI <0(2), graphite_IV.5_5(9)>
> ? ? ?# .MEM_37 = PHI <.MEM_13(D)(2), .MEM_38(9)>
> ? ? ?D.3185_12 = graphite_IV.5_17 + 0x0ffffffe3;
> ? ? ?D.3186_11 = MAX_EXPR <D.3185_12, 0>; # this is the line in question
It looks like D.3185 is unsigned.
Richard.
> ? ? ?D.3187_23 = MIN_EXPR <graphite_IV.5_17, 19>;
> ? ? ?D.3188_24 = D.3187_23 + 1;
> ? ? ?D.3189_25 = D.3186_11 < D.3188_24;
> ? ? ?if (D.3189_25 != 0)
> ? ? ? ?goto <bb 4>;
> ? ? ?else
> ? ? ? ?goto <bb 8>;
> </file>
>
> Curiously, the line marked above doesn't work in assembly. The
> D.3186_11 is assigned to -29, although zero is greater than that, and
> the code inside the loop body never runs.
> Moreover, If I get the clast code generated by cloog after the skewing
> (above), and put it on the source file (compiling without skeking),
> the max expr appears in gimple as an if statement, and the code
> executes perfectly.
>
> Does someone have any idea how could I fix it??
>
> Thanks in advance,
>
> On Sun, Feb 7, 2010 at 7:31 PM, Cristianno Martins
> <cristiannomartins@gmail.com> wrote:
>>
>> Hello everyone,
>>
>> I've working on graphite lately, and I did an loop skewing
>> implementation, starting from the loop interchange code [in
>> gcc/graphite-interchange.c].
>> However, after the transformation, if I print the clast generated by
>> Cloog, what I get is a almost the same loop as the original one.
>> Moreover, if I write the pbb transformed domain and scattering into a
>> file, and run the cloog command with that file, the result is exactly
>> what I want from the beggining.
>> For better comprehension of the problem, some interesting data are showed below.
>>
>> But, first, for short, my question is: am I forgetting something
>> important that I must be doing (like a function call)?
>>
>>
>>> [...]
>>
>> Thanks in advance,
>>
>> --
>> Cristianno Martins
>
> --
> Cristianno Martins
>