Inner loop unable to compute sufficient information during vectorization

Inner loop unable to compute sufficient information during vectorization

[Abhishek Shrivastav]

for a loop like

1         for(i=0;i<N;i++)
2           for(j=0;j<N;j++)
3               a[i][j] = a[i][j]+b[i][j];

GCC 4.3.* is unable to get the information for the inner loop that
array reference 'a'  is alias of each other and generates code for
runtime aliasing check during vectorization. Is it necessary to
recompute all information in loop_vec_info in function
vect_analyze_ref for analysis of inner loop also, as most of the
information is similar for the outer loop for the program.

Similarly, outer loop is able to compute correct chrec i.e. NULL , for
array 'a' reference, while innerloop has chrec as chrec_dont_know, and
therfore complaint about runtime alias check.

Re: Inner loop unable to compute sufficient information during vectorization

[Ira Rosen]

gcc-owner@gcc.gnu.org wrote on 25/05/2009 21:53:41:

> for a loop like
>
> 1         for(i=0;i<N;i++)
> 2           for(j=0;j<N;j++)
> 3               a[i][j] = a[i][j]+b[i][j];
>
> GCC 4.3.* is unable to get the information for the inner loop that
> array reference 'a'  is alias of each other and generates code for
> runtime aliasing check during vectorization.

Both current trunk and GCC4.4 vectorize the inner loop without any runtime
alias checks.

> Is it necessary to
> recompute all information in loop_vec_info in function
> vect_analyze_ref for analysis of inner loop also, as most of the
> information is similar for the outer loop for the program.

Maybe you are right, and it is possible to extract at least part of the
information for the inner loop from the outer loop information.

>
> Similarly, outer loop is able to compute correct chrec i.e. NULL , for
> array 'a' reference, while innerloop has chrec as chrec_dont_know, and
> therfore complaint about runtime alias check.

The chrecs are not the same for inner and outer loops, so it is reasonable
that the results of the data dependence tests will be different.
In this case, however, it seems to be a bug.

Ira

Re: Inner loop unable to compute sufficient information during vectorization

[Ira Rosen]

Abhishek Shrivastav <abhishek.shrivastav24@gmail.com> wrote on 31/05/2009
16:44:34:

> In this case, I think that Outer loop could be vectorized as there is
> no dependency in the loop,the access pattern is simple enough and
> there is unit stride in both the loops. Current version 4.4.* is not
> doing outer loop vectorization.

The memory accesses are consecutive in the inner loop and strided in the
outer loop. Therefore, inner loop vectorization is preferable in this case
(and also strided accesses are not yet supported in outer loop
vectorization).

Ira

>
> On Tue, May 26, 2009 at 5:57 PM, Ira Rosen <IRAR@il.ibm.com> wrote:
> >
> >
> > gcc-owner@gcc.gnu.org wrote on 25/05/2009 21:53:41:
> >
> >> for a loop like
> >>
> >> 1         for(i=0;i<N;i++)
> >> 2           for(j=0;j<N;j++)
> >> 3               a[i][j] = a[i][j]+b[i][j];
> >>
> >> GCC 4.3.* is unable to get the information for the inner loop that
> >> array reference 'a'  is alias of each other and generates code for
> >> runtime aliasing check during vectorization.
> >
> > Both current trunk and GCC4.4 vectorize the inner loop without any
runtime
> > alias checks.
> >
> >> Is it necessary to
> >> recompute all information in loop_vec_info in function
> >> vect_analyze_ref for analysis of inner loop also, as most of the
> >> information is similar for the outer loop for the program.
> >
> > Maybe you are right, and it is possible to extract at least part of the
> > information for the inner loop from the outer loop information.
> >
> >>
> >> Similarly, outer loop is able to compute correct chrec i.e. NULL , for
> >> array 'a' reference, while innerloop has chrec as chrec_dont_know, and
> >> therfore complaint about runtime alias check.
> >
> > The chrecs are not the same for inner and outer loops, so it is
reasonable
> > that the results of the data dependence tests will be different.
> > In this case, however, it seems to be a bug.
> >
> > Ira
> >
> >
> >
> >