[Bug tree-optimization/50522] New: C++ std::valarray vectorization missed optimization

[Bug tree-optimization/50522] New: C++ std::valarray vectorization missed optimization

[jakub at gcc dot gnu.org]

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

             Bug #: 50522
           Summary: C++ std::valarray vectorization missed optimization
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jakub@gcc.gnu.org
                CC: irar@gcc.gnu.org, jason@gcc.gnu.org,
                    rguenth@gcc.gnu.org


#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.

[Bug tree-optimization/50522] C++ std::valarray vectorization missed optimization

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-09-26 08:23:15 UTC ---
Created attachment 25365
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25365
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.

[Bug tree-optimization/50522] C++ std::valarray vectorization missed optimization

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-09-26
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-09-26 10:36:38 UTC ---
(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 ...

[Bug tree-optimization/50522] C++ std::valarray vectorization missed optimization

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-10-04 13:36:29 UTC ---
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

[Bug tree-optimization/50522] C++ std::valarray vectorization missed optimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-10-04 15:31:44 UTC ---
Fixed.