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 + 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
>> <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
