public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexander Monakov <amonakov@ispras.ru>
To: Richard Guenther <richard.guenther@gmail.com>
Cc: Sebastian Pop <sebpop@gmail.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PR46761] graphite: fix testing of boundary wrapping
Date: Wed, 15 Dec 2010 16:20:00 -0000	[thread overview]
Message-ID: <alpine.LNX.2.00.1012151836470.5687@monoid.intra.ispras.ru> (raw)
In-Reply-To: <AANLkTi=fu253h21PJDmRNnPcQdO_Q+X-Qc5+mAd4WOfy@mail.gmail.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3440 bytes --]



On Mon, 13 Dec 2010, Richard Guenther wrote:

> 2010/12/13 Sebastian Pop <sebpop@gmail.com>:
> > On Mon, Dec 13, 2010 at 07:40, Alexander Monakov <amonakov@ispras.ru> wrote:
> >> Hi,
> >>
> >> As indicated by the testcase, sometimes Graphite would generate wrong region
> >> guards if UB_ONE overflows, but does not become zero (i.e. it is signed).
> >> The patch changes the corresponding test to use TREE_OVERFLOW flag.
> >>
> >> Bootstrapped and regtested on x86_64-linux, OK for trunk?
> >>
> >> 2010-12-13  Alexander Monakov  <amonakov@ispras.ru>
> >>
> >>        PR middle-end/46761
> >>        * graphite-clast-to-gimple.c (graphite_create_new_loop_guard): Use
> >>        TREE_OVERFLOW_P to test overflow.
> >>
> >> testsuite:
> >>        * gcc.dg/graphite/pr46761.c: New.
> >>
> >
> > Ok.  Thanks for fixing this,
> 
> Hmm, I don't like new uses of TREE_OVERFLOW checking.  And for
> unsigned types it won't be set anyway.

Thanks.  The following patch changes guard generation so that using unadjusted
UB is preferred (if it's an integer constant or an SSA_NAME).  If it is
neither, it uses the previous behaviour of bumping UB by one and changing the
test.  Bootstrapped and tested with make -k check RUNTESTFLAGS="graphite.exp",
OK for trunk?

2010-12-15  Alexander Monakov  <amonakov@ispras.ru>

        PR middle-end/46761
        * graphite-clast-to-gimple.c (graphite_create_new_loop_guard): Prefer
        to use unadjusted UB.

diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index 4894b52..4725608 100644
--- a/gcc/graphite-clast-to-gimple.c
+++ b/gcc/graphite-clast-to-gimple.c
@@ -975,20 +975,24 @@ graphite_create_new_loop_guard (sese region, edge entry_edge,
 				     newivs_index, params_index);
   tree ub = clast_to_gcc_expression (type, stmt->UB, region, newivs,
 				     newivs_index, params_index);
-  tree one = POINTER_TYPE_P (type) ? size_one_node
-    : fold_convert (type, integer_one_node);
-  /* Adding +1 and using LT_EXPR helps with loop latches that have a
-     loop iteration count of "PARAMETER - 1".  For PARAMETER == 0 this becomes
-     2^{32|64}, and the condition lb <= ub is true, even if we do not want this.
-     However lb < ub + 1 is false, as expected.  */
-  tree ub_one = fold_build2 (POINTER_TYPE_P (type) ? POINTER_PLUS_EXPR
-			     : PLUS_EXPR, type, ub, one);
-
-  /* When ub + 1 wraps around, use lb <= ub.  */
-  if (integer_zerop (ub_one))
+  /* When ub is simply a constant or a parameter, use lb <= ub.  */
+  if (TREE_CODE (ub) == INTEGER_CST || TREE_CODE (ub) == SSA_NAME)
     cond_expr = fold_build2 (LE_EXPR, boolean_type_node, lb, ub);
   else
-    cond_expr = fold_build2 (LT_EXPR, boolean_type_node, lb, ub_one);
+    {
+      tree one = (POINTER_TYPE_P (type)
+		  ? size_one_node
+		  : fold_convert (type, integer_one_node));
+      /* Adding +1 and using LT_EXPR helps with loop latches that have a
+	 loop iteration count of "PARAMETER - 1".  For PARAMETER == 0 this becomes
+	 2^k-1 due to unsigned overflow, and the condition lb <= ub is true,
+	 even if we do not want this.  However lb < ub + 1 is false, as
+	 expected.  */
+      tree ub_one = fold_build2 (POINTER_TYPE_P (type) ? POINTER_PLUS_EXPR
+				 : PLUS_EXPR, type, ub, one);
+
+      cond_expr = fold_build2 (LT_EXPR, boolean_type_node, lb, ub_one);
+    }
 
   exit_edge = create_empty_if_region_on_edge (entry_edge, cond_expr);
 

  reply	other threads:[~2010-12-15 15:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-13 14:44 Alexander Monakov
2010-12-13 16:36 ` Sebastian Pop
2010-12-13 17:31   ` Richard Guenther
2010-12-15 16:20     ` Alexander Monakov [this message]
2010-12-16 11:57       ` Richard Guenther
2010-12-16 22:29         ` Alexander Monakov
2010-12-16 23:21           ` Sebastian Pop

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.LNX.2.00.1012151836470.5687@monoid.intra.ispras.ru \
    --to=amonakov@ispras.ru \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    --cc=sebpop@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).