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

Reply via email to