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 <[email protected]>
>
> 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 <[email protected]>
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
