Re: Overlap Iterations in Dependence testing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I guess the step in chrec is to be multiplied with the whole
overlap_iteration_a, and then the init value is to be added. This
gives 22 + 0 = 22.
in overlap_iterations_b, 21 + 1 = 22. So the overlap_iterations are right.
But can anyone shed light on how the last_conflict came out to be 63?

On Fri, May 6, 2011 at 2:52 AM, Prashant Singh Rawat
<prashant.srawat86@xxxxxxxxx> wrote:
> In gcc 4.6.0, The part of dump (*.ckdd) finding the dependency using
> Banerjee's Solver for the program
> | int a[256];
> | int main ()
> | {
> |    int i;
> |     for (i=0; i<200; i++)
> |        a[i+21] = a[i*2] + 2;
> | }
>
> gives,
> chrec_a = {0, +, 2}_1
> chrec_b = {21, +, 1}_1
>
> and the overlap_iterations are :
> overlap_iterations_a = [11 + 1 * x_1]
> overlap_iterations_b = [1 + 2 * x_1]
>
> What I understood was that overlap_iterations give the solution to the
> Diophantine equation. In that light, is this solution not incorrect?
> Or there is something wrong with my understanding?
> Also, what does last_conflict hold? The last iteration number of
> source that causes conflict, or the total number of iterations that
> cause conflict?
> In case of variable dependence distance, even the last_conflict seems
> to have wrong value. In this example, it is 63. Why?
>
>
>
> --
> With regards,
> Prashant Singh Rawat
> http://www.cse.iitb.ac.in/~prashantr
>



-- 
With regards,
Prashant Singh Rawat
http://www.cse.iitb.ac.in/~prashantr



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux