Re: [GRAPHITE] Re: Loop Transformations Question
On Tue, Feb 9, 2010 at 6:01 PM, Cristianno Martins
cristiannomart...@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 + 0x0ffe3;
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
cristiannomart...@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
Re: [GRAPHITE] Re: Loop Transformations Question
Hi,
Thanks for the fast reply. Only one more thing: is there some way that
I could force it to be signed??
On Tue, Feb 9, 2010 at 3:17 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Feb 9, 2010 at 6:01 PM, Cristianno Martins
cristiannomart...@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 + 0x0ffe3;
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
cristiannomart...@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
--
Cristianno Martins
Mestrando em Computação
Universidade Estadual de Campinas
cristianno.mart...@students.ic.unicamp.br
cel: (19) 8825-5731 [oi]
(19) 8240-3217 [tim]
skype: cristiannomartins
gTalk: cristiannomartins
msn: cristiannomart...@hotmail.com
Re: [GRAPHITE] Re: Loop Transformations Question
On Tue, Feb 9, 2010 at 12:34, Cristianno Martins
cristiannomart...@gmail.com wrote:
Hi,
Thanks for the fast reply. Only one more thing: is there some way that
I could force it to be signed??
I guess that you should wait the fixes from Tobias and Ramakrishna to
CLooG and Graphite to have the type of the IV exposed by CLooG, rather
than having the original IV type set to the generated IV.
Sebastian
On Tue, Feb 9, 2010 at 3:17 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Feb 9, 2010 at 6:01 PM, Cristianno Martins
cristiannomart...@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 + 0x0ffe3;
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
cristiannomart...@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
--
Cristianno Martins
Mestrando em Computação
Universidade Estadual de Campinas
cristianno.mart...@students.ic.unicamp.br
cel: (19) 8825-5731 [oi]
(19) 8240-3217 [tim]
skype: cristiannomartins
gTalk: cristiannomartins
msn: cristiannomart...@hotmail.com
Re: [GRAPHITE] Re: Loop Transformations Question
On 09.02.2010 19:39, Sebastian Pop wrote: On Tue, Feb 9, 2010 at 12:34, Cristianno Martins cristiannomart...@gmail.com wrote: Hi, Thanks for the fast reply. Only one more thing: is there some way that I could force it to be signed?? I guess that you should wait the fixes from Tobias and Ramakrishna to CLooG and Graphite to have the type of the IV exposed by CLooG, rather than having the original IV type set to the generated IV. Sebastian Yes it looks as this is one of the bugs Ramakrishna and me are working on. In short the reason for the bugs seems to be that the loop induction variable is converted to an unsigned int. Later cloog generates a statement that is negative and assigned to the unsigned int. Instead of this expression iv -something being false the signed value is wrapped to an unsigned one. Therefore the whole expression becomes true. I will have a look into this one. Tobias
