On Mon, 26 Sep 2011, Jakub Jelinek wrote: > Hi! > > As discussed in the PR, we currently don't vectorize > #include <valarray> > > std::valarray<int> > f1 (std::valarray<int> a, std::valarray<int> b, std::valarray<int> c, int z) > { > int i; > for (i = 0; i < z; i++) > { > a[i] = b[i] + c[i]; > a[i] += b[i] * c[i]; > } > return a; > } > > void > f2 (std::valarray<int> &__restrict a, std::valarray<int> &__restrict b, > std::valarray<int> &__restrict c, int z) > { > int i; > for (i = 0; i < z; i++) > { > a[i] = b[i] + c[i]; > a[i] += b[i] * c[i]; > } > } > > because while the ptr loaded from _M_data is TYPE_RESTRICT, the > reference computed as that pointer plus i * 4 that results from inling > is not TYPE_RESTRICT. > > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, > ok for trunk?
Let's see what kind of fallout we get ;) For example, if the following is valid C code I expect we will vectorize the second loop (disambiguating p[i] and q[i]) bogously: void foo (int *p) { int * __restrict p1 = p; int * __restrict p2 = p + 32; int *q; int i; for (i = 0; i < 32; ++i) p1[i] = p2[i]; p = p1; q = p2 - 31; for (i = 0; i < 32; ++i) p[i] = q[i]; } because p and q base on different restrict qualified pointers (p1 and p2 respective). At the moment we are safe from this because of the TYPE_RESTRICT checks. Any opinion on the above? Is it valid to base non-restrict pointers on restrict ones? It would be sort-of weird at least, but at least I don't think the first loop use is bogus (even though the pointed-to objects are the same). Thanks, Richard. > 2011-09-26 Jakub Jelinek <ja...@redhat.com> > > PR tree-optimization/50522 > * tree-ssa-alias.c (ptr_deref_may_alias_decl_p): Don't test > TYPE_RESTRICT. > (ptr_derefs_may_alias_p): Call pt_solutions_same_restrict_base > unconditionally. > > --- gcc/tree-ssa-alias.c.jj 2011-09-15 12:18:37.000000000 +0200 > +++ gcc/tree-ssa-alias.c 2011-09-26 13:49:24.000000000 +0200 > @@ -223,7 +223,6 @@ ptr_deref_may_alias_decl_p (tree ptr, tr > pointer and that pointers points-to set doesn't contain this decl > then they can't alias. */ > if (DECL_RESTRICTED_P (decl) > - && TYPE_RESTRICT (TREE_TYPE (ptr)) > && pi->pt.vars_contains_restrict) > return bitmap_bit_p (pi->pt.vars, DECL_PT_UID (decl)); > > @@ -319,9 +318,7 @@ ptr_derefs_may_alias_p (tree ptr1, tree > > /* If both pointers are restrict-qualified try to disambiguate > with restrict information. */ > - if (TYPE_RESTRICT (TREE_TYPE (ptr1)) > - && TYPE_RESTRICT (TREE_TYPE (ptr2)) > - && !pt_solutions_same_restrict_base (&pi1->pt, &pi2->pt)) > + if (!pt_solutions_same_restrict_base (&pi1->pt, &pi2->pt)) > return false; > > /* ??? This does not use TBAA to prune decls from the intersection > > Jakub > > -- Richard Guenther <rguent...@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer