#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]; } } should be vectorizable (f2 only since http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179166 ), but it is not. There seems to be 2 problems: 1) from the inlines we unfortunately have pointers (resp. references) initialized from TYPE_RESTRICT pointers, which don't have TYPE_RESTRICT themselves. --- tree-ssa-alias.c.jj 2011-09-15 12:18:37.000000000 +0200 +++ tree-ssa-alias.c 2011-09-26 09:10:50.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,8 +318,8 @@ 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)) + if (pi1->pt.vars_contains_restrict + && pi2->pt.vars_contains_restrict && !pt_solutions_same_restrict_base (&pi1->pt, &pi2->pt)) return false; seems to fix that part, but maybe it is too unsafe (would e.g. vars_contains_restrict propagate through cast of a pointer to integer and back?). Maybe just a quick hack of allowing either TYPE_RESTRICT, or POINTER_TYPE_P SSA_NAME initialized from either a pointer cast or POINTER_PLUS_EXPR from a TYPE_RESTRICT pointer would be enough to fix this and don't regress problematic __restrict cases (richi, which are the currently known ones?). 2) even with that change, the vectorizer didn't vectorize this. But apparently this turned out to be something Eric fixed over the weekend - r179165 - where simple_iv checked just for POINTER_TYPE and not for POINTER_TYPE_P.
Created attachment 25365 [details] gcc47-pr50522-hack.patch The perhaps safer hack, which handles only pointers initialized from casted TYPE_RESTRICT or POINTER_PLUS_EXPR of TYPE_RESTRICT. Both functions are still vectorized.
(In reply to comment #1) > Created attachment 25365 [details] > gcc47-pr50522-hack.patch > > The perhaps safer hack, which handles only pointers initialized from > casted TYPE_RESTRICT or POINTER_PLUS_EXPR of TYPE_RESTRICT. Both functions are > still vectorized. Looks like a hack ;) Restrict support was designed to work without the TYPE_RESTRICT checks but ISTR there were miscompiles without adding them - maybe all latent issues have been fixed now, but you might run into PR48764 more often. Restrict will propagate through ptr/int/ptr conversions but should end up aliased whenever two resulting pointers are based off the same initial restrict tag. Thus, if removing TYPE_RESTRICT checks bootstraps and tests ok, I'd approve that patch ...
Author: jakub Date: Tue Oct 4 13:36:24 2011 New Revision: 179502 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179502 Log: 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. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias.c
Fixed.