This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/49760] vectorization inhibited if indices are references


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49760

--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> 2011-07-18 09:44:23 UTC ---
On Mon, 18 Jul 2011, vincenzo.innocente at cern dot ch wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49760
> 
> --- Comment #2 from vincenzo Innocente <vincenzo.innocente at cern dot ch> 2011-07-18 09:39:49 UTC ---
> Thanks for the detailed explanation.
> In the real life code, "out" is filled  calling "foo" multiple times (a sort of
> nested loop), "k" was used to track the current size of it.
> It is true that in this particular case  I can just  k+=N; at the end of the
> loop.
> 
> The issue is more with 
> "for (int i=0; i!=in.size; ++i)" as in foo2 
> because of
> "not vectorized: number of iterations cannot be computed"
> while copying it locally in N works.

Probably the same issue - the out array may point to in.size and
thus clobber it (yes - only if the loop runs exactly once, but we
don't use that information yet).

> 
> b.t.w.
> void foo(SoA const & __restrict__ in, SoB & __restrict__ out, int &
> __restrict__ k) {
>   int N=in.size;
>   for (int i=0; i!=N; ++i) {
>     out.b[k] = in.c[i]+in.b[i];
>     out.a[k] = in.a[i];
>     ++k;
>   }
> }
> does not vectorize either

I suppose we can't vectorize the k iterator (or rather we don't
apply store motion).  You should avoid using induction variables
that live in memory.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]