Hi!

This simple patch improves the f3 function in the testcase below,
a parameter with TYPE_RESTRICT REFERENCE_TYPE IMHO can be safely treated
like the DECL_BY_REFERENCE case where the source actually didn't contain
a reference, but compiler created it anyway.  If source contains &__restrict
parameter, the parameter again points to a chunk of (for the function
global) restrict memory that nothing inside of the function should access
otherwise than through this parameter or pointers derived from it.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2011-09-23  Jakub Jelinek  <ja...@redhat.com>

        * tree-ssa-structalias.c (intra_create_variable_infos): Treat
        TYPE_RESTRICT REFERENCE_TYPE parameters like restricted
        DECL_BY_REFERENCE parameters.

        * g++.dg/tree-ssa/restrict2.C: New test.

--- gcc/tree-ssa-structalias.c.jj       2011-09-15 12:18:37.000000000 +0200
+++ gcc/tree-ssa-structalias.c  2011-09-23 15:36:23.000000000 +0200
@@ -5589,10 +5589,11 @@ intra_create_variable_infos (void)
       varinfo_t p;
 
       /* For restrict qualified pointers to objects passed by
-         reference build a real representative for the pointed-to object.  */
-      if (DECL_BY_REFERENCE (t)
-         && POINTER_TYPE_P (TREE_TYPE (t))
-         && TYPE_RESTRICT (TREE_TYPE (t)))
+         reference build a real representative for the pointed-to object.
+        Treat restrict qualified references the same.  */
+      if (TYPE_RESTRICT (TREE_TYPE (t))
+         && ((DECL_BY_REFERENCE (t) && POINTER_TYPE_P (TREE_TYPE (t)))
+             || TREE_CODE (TREE_TYPE (t)) == REFERENCE_TYPE))
        {
          struct constraint_expr lhsc, rhsc;
          varinfo_t vi;
--- gcc/testsuite/g++.dg/tree-ssa/restrict2.C.jj        2011-09-23 
16:11:27.000000000 +0200
+++ gcc/testsuite/g++.dg/tree-ssa/restrict2.C   2011-09-23 16:10:28.000000000 
+0200
@@ -0,0 +1,62 @@
+// { dg-do compile }
+// { dg-options "-O2 -fdump-tree-optimized" }
+
+struct S { int *__restrict p; int q; };
+S s;
+
+int
+f1 (S x, S y)
+{
+  x.p[0] = 1;
+  y.p[0] = 0;
+// { dg-final { scan-tree-dump-times "return 1" 1 "optimized" } }
+  return x.p[0];
+}
+
+int
+f2 (S x)
+{
+  x.p[0] = 2;
+  s.p[0] = 0;
+// { dg-final { scan-tree-dump-times "return 2" 1 "optimized" } }
+  return x.p[0];
+}
+
+int
+f3 (S &__restrict x, S &__restrict y)
+{
+  x.p[0] = 3;
+  y.p[0] = 0;
+// { dg-final { scan-tree-dump-times "return 3" 1 "optimized" } }
+  return x.p[0];
+}
+
+int
+f4 (S &x, S &y)
+{
+  x.p[0] = 4;
+  y.p[0] = 0;
+// { dg-final { scan-tree-dump-times "return 4" 0 "optimized" } }
+  return x.p[0];
+}
+
+int
+f5 (S *__restrict x, S *__restrict y)
+{
+  x->p[0] = 5;
+  y->p[0] = 0;
+// We might handle this some day
+// { dg-final { scan-tree-dump-times "return 5" 0 "optimized" } }
+  return x->p[0];
+}
+
+int
+f6 (S *x, S *y)
+{
+  x->p[0] = 6;
+  y->p[0] = 0;
+// { dg-final { scan-tree-dump-times "return 6" 0 "optimized" } }
+  return x->p[0];
+}
+
+// { dg-final { cleanup-tree-dump "optimized" } }

        Jakub

Reply via email to