public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Jan Hubicka <hubicka@ucw.cz>
Cc: Richard Biener <richard.guenther@gmail.com>,
	    GCC Patches <gcc-patches@gcc.gnu.org>,
	d@dcepelik.cz, mjambor@suse.cz
Subject: Re: Teach same_types_for_tbaa to structurally compare arrays, pointers and vectors
Date: Fri, 31 May 2019 12:50:00 -0000	[thread overview]
Message-ID: <alpine.LSU.2.20.1905311346200.10704@zhemvz.fhfr.qr> (raw)
In-Reply-To: <20190529195839.jmp32xu6v6a6dhjn@kam.mff.cuni.cz>

On Wed, 29 May 2019, Jan Hubicka wrote:

> Hi,
> this is a variant of testcase I have comitted. Once Martin implements SRA
> part, we could add next variant that drops -fno-tree-sra.
> 
> It seems odd that constant propagation only happens in fre3.
> I woud expect fre1 to discover this already.
> The IL before fre1 and 3 differs only by:
> 
>  test ()
>  {
>    struct foo foo;
>    struct bar * barptr.0_1;
>    struct foo * fooptr.1_2;
> -  struct bar * barptr.2_3;
> -  int _8;
> +  int _7;
>  
> -  <bb 2> :
> +  <bb 2> [local count: 1073741824]:
>    foo.val = 0;
>    barptr.0_1 = barptr;
>    barptr.0_1->val2 = 123;
>    fooptr.1_2 = fooptr;
>    *fooptr.1_2 = foo;
> -  barptr.2_3 = barptr;
> -  _8 = barptr.2_3->val2;
> +  _7 = barptr.0_1->val2;
>    foo ={v} {CLOBBER};
> -  return _8;
> +  return _7;
>  
>  }
> 
> Why VN is not able to optimize the barptr access and lookup through
> it at once?  It looks that could potentially save some need to re-run
> GVN since it is common to store pointers to memory and use them multiple
> times to access other pointers.

This is because in the first pass we substitute the value of
barptr.2_3 (barptr.0_1) when looking up barptr.2_3->val2 and
since that happens in VNs IL we run into
ao_ref_init_from_vn_reference which does not re-build
a GENERIC tree for the access path but leaves us with NULL
ao_ref.ref -- I suppose we could put the original ref tree
in there, too, even if the pieces are "valueized", it's just
a more imprecise representation of the ref.

That helps this testcase.

Bootstrap / regtest running on x86_64-unknown-linux-gnu.

Richard.

2019-05-31  Richard Biener  <rguenther@suse.de>

	* tree-ssa-sccvn.c (ao_ref_init_from_vn_reference): Get original
	full reference tree and record in ref->ref.
	(vn_reference_lookup_3): Pass in original ref to
	ao_ref_init_from_vn_reference.
	(vn_reference_lookup): Likewise.
	* tree-ssa-sccvn.h (ao_ref_init_from_vn_reference): Adjust prototype.

	* gcc.dg/tree-ssa/alias-access-path-1.c: Scan fre1.

Index: gcc/tree-ssa-sccvn.c
===================================================================
--- gcc/tree-ssa-sccvn.c	(revision 271803)
+++ gcc/tree-ssa-sccvn.c	(working copy)
@@ -995,7 +995,7 @@ copy_reference_ops_from_ref (tree ref, v
 bool
 ao_ref_init_from_vn_reference (ao_ref *ref,
 			       alias_set_type set, tree type,
-			       vec<vn_reference_op_s> ops)
+			       vec<vn_reference_op_s> ops, tree orig_ref)
 {
   vn_reference_op_t op;
   unsigned i;
@@ -1149,7 +1149,7 @@ ao_ref_init_from_vn_reference (ao_ref *r
   if (base == NULL_TREE)
     return false;
 
-  ref->ref = NULL_TREE;
+  ref->ref = orig_ref;
   ref->base = base;
   ref->ref_alias_set = set;
   if (base_alias_set != -1)
@@ -1976,7 +1976,8 @@ vn_reference_lookup_3 (ao_ref *ref, tree
 	{
 	  lhs_ref_ok = ao_ref_init_from_vn_reference (&lhs_ref,
 						      get_alias_set (lhs),
-						      TREE_TYPE (lhs), lhs_ops);
+						      TREE_TYPE (lhs), lhs_ops,
+						      lhs);
 	  if (lhs_ref_ok
 	      && !refs_may_alias_p_1 (ref, &lhs_ref, true))
 	    {
@@ -2718,7 +2719,7 @@ vn_reference_lookup (tree op, tree vuse,
          Otherwise preserve the full reference for advanced TBAA.  */
       if (!valuezied_anything
 	  || !ao_ref_init_from_vn_reference (&r, vr1.set, vr1.type,
-					     vr1.operands))
+					     vr1.operands, op))
 	ao_ref_init (&r, op);
       if (! tbaa_p)
 	r.ref_alias_set = r.base_alias_set = 0;
Index: gcc/tree-ssa-sccvn.h
===================================================================
--- gcc/tree-ssa-sccvn.h	(revision 271803)
+++ gcc/tree-ssa-sccvn.h	(working copy)
@@ -229,7 +229,7 @@ vn_nary_op_t vn_nary_op_insert (tree, tr
 vn_nary_op_t vn_nary_op_insert_pieces (unsigned int, enum tree_code,
 				       tree, tree *, tree, unsigned int);
 bool ao_ref_init_from_vn_reference (ao_ref *, alias_set_type, tree,
-				    vec<vn_reference_op_s> );
+				    vec<vn_reference_op_s>, tree = NULL_TREE);
 vec<vn_reference_op_s> vn_reference_operands_for_lookup (tree);
 tree vn_reference_lookup_pieces (tree, alias_set_type, tree,
 				 vec<vn_reference_op_s> ,
Index: gcc/testsuite/gcc.dg/tree-ssa/alias-access-path-1.c
===================================================================
--- gcc/testsuite/gcc.dg/tree-ssa/alias-access-path-1.c	(revision 271803)
+++ gcc/testsuite/gcc.dg/tree-ssa/alias-access-path-1.c	(working copy)
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-fre3 -fno-tree-sra" } */
+/* { dg-options "-O2 -fdump-tree-fre1 -fno-tree-sra" } */
+
 struct foo
 {
   int val;
@@ -18,4 +19,4 @@ test ()
   return barptr->val2;
 }
 
-/* { dg-final { scan-tree-dump-times "return 123" 1 "fre3"} } */
+/* { dg-final { scan-tree-dump-times "return 123" 1 "fre1"} } */

  reply	other threads:[~2019-05-31 11:56 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-24 11:14 Jan Hubicka
2019-05-24 12:57 ` Richard Biener
2019-05-24 13:19   ` Jan Hubicka
2019-05-27  7:16     ` Richard Biener
2019-05-27  8:32       ` Jan Hubicka
2019-05-29 12:28         ` Richard Biener
2019-05-29 13:24           ` Jan Hubicka
2019-05-29 13:31             ` Richard Biener
2019-05-29 14:13               ` Jan Hubicka
2019-05-30 16:23                 ` Martin Jambor
     [not found]                   ` <alpine.LSU.2.20.1905311402280.10704@zhemvz.fhfr.qr>
     [not found]                     ` <ri6blzdaer9.fsf@suse.cz>
     [not found]                       ` <alpine.LSU.2.20.1906061503090.10704@zhemvz.fhfr.qr>
2019-06-06 16:00                         ` Martin Jambor
2019-05-29 20:00               ` Jan Hubicka
2019-05-31 12:50                 ` Richard Biener [this message]
2019-05-27 13:57       ` Jan Hubicka
2019-05-29 12:33         ` Richard Biener
2019-05-29 12:36           ` Jan Hubicka
2019-05-29 12:56             ` Richard Biener
2019-05-29 13:32               ` Jan Hubicka
2019-05-24 13:48   ` Jan Hubicka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LSU.2.20.1905311346200.10704@zhemvz.fhfr.qr \
    --to=rguenther@suse.de \
    --cc=d@dcepelik.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=mjambor@suse.cz \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).