public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "law at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code
Date: Tue, 08 Mar 2022 17:25:08 +0000	[thread overview]
Message-ID: <bug-40073-4-Uc8zRL4aDC@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-40073-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073

--- Comment #19 from Jeffrey A. Law <law at gcc dot gnu.org> ---
I stumbled over this as well as some point.   One thing I started playing with,
but had to set aside was making vect_get_range_info smarter.

In particular the case I was looking at VAR would have a single use that was a
narrowing conversion.  Taking advantage of that narrowing conversion would tend
to allow us to use VxQI and VxHI shifts more often.

It's just something we noticed, but never chased down if it was important in
terms of real world code generation.  I see two patches in my stash.  No idea
the state on either one, but they might point you at something useful...


diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
index 803de3fc287..43369eb8f4e 100644
--- a/gcc/tree-vect-patterns.c
+++ b/gcc/tree-vect-patterns.c
@@ -58,6 +58,37 @@ vect_get_range_info (tree var, wide_int *min_value, wide_int
*max_value)
   value_range_kind vr_type = get_range_info (var, min_value, max_value);
   wide_int nonzero = get_nonzero_bits (var);
   signop sgn = TYPE_SIGN (TREE_TYPE (var));
+
+  /* If VAR has a single use in a narrowing conversion, then we may be
+     able to use the narrowing conversion to get a tighter range.  */
+  gimple *use_stmt;
+  use_operand_p use;
+  if (vr_type == VR_VARYING
+      && single_imm_use (var, &use, &use_stmt)
+      && is_gimple_assign (use_stmt)
+      && gimple_assign_rhs_code (use_stmt) == NOP_EXPR)
+    {
+      /* We know VAR has a single use that is a conversion.  Now check
+        if it is a narrowing conversion.  */
+      tree lhs = gimple_assign_lhs (use_stmt);
+      unsigned HOST_WIDE_INT orig_size = tree_to_uhwi (TYPE_SIZE (TREE_TYPE
(var)));
+      unsigned HOST_WIDE_INT lhs_size = tree_to_uhwi (TYPE_SIZE (TREE_TYPE
(lhs)));
+
+      if (lhs_size < orig_size)
+       {
+         /* The single use of VAR was a narrowing conversion.
+            Use the nonzero bits from the narrower type and
+            the min/max values of VAR's type.
+
+            This allows the intersect call below to work in the expected way. 
*/
+         nonzero = get_nonzero_bits (lhs);
+         sgn = TYPE_SIGN (TREE_TYPE (lhs));
+         *min_value = wi::to_wide (vrp_val_min (TREE_TYPE (lhs)));
+         *max_value = wi::to_wide (vrp_val_min (TREE_TYPE (lhs)));
+         vr_type = VR_RANGE;
+       }
+    }
+
   if (intersect_range_with_nonzero_bits (vr_type, min_value, max_value,
                                         nonzero, sgn) == VR_RANGE)
     {


And another variant:

@@ -74,6 +74,38 @@ vect_get_range_info (tree var, wide_int *min_value, wide_int
*max_value)
     }
   else
     {
+      /* Try a bit harder to get a narrowed range.  If VAR has a single use
that
+        is a conversion, see if we can use the converted range.  */
+      gimple *stmt;
+      use_operand_p use;
+      if (single_imm_use (var, &use, &stmt)
+         && is_gimple_assign (stmt)
+         && gimple_assign_rhs_code (stmt) == NOP_EXPR)
+       {
+         /* If this is a narrowing conversion, then we win as it
+            narrows the range of VAR.  */
+         tree lhs = gimple_assign_lhs (stmt);
+         unsigned HOST_WIDE_INT orig_size = tree_to_uhwi (TYPE_SIZE (TREE_TYPE
(var)));
+         unsigned HOST_WIDE_INT lhs_size = tree_to_uhwi (TYPE_SIZE (TREE_TYPE
(lhs)));
+         if (lhs_size < orig_size)
+           {
+             *min_value = wi::to_wide (TYPE_MIN_VALUE (TREE_TYPE (lhs)));
+             *max_value = wi::to_wide (TYPE_MAX_VALUE (TREE_TYPE (lhs)));
+             if (dump_enabled_p ())
+               {
+                 dump_generic_expr_loc (MSG_NOTE, vect_location, TDF_SLIM,
var);
+                 dump_printf (MSG_NOTE, " has range [");
+                 dump_hex (MSG_NOTE, *min_value);
+                 dump_printf (MSG_NOTE, ", ");
+                 dump_hex (MSG_NOTE, *max_value);
+                 dump_printf (MSG_NOTE, "]\n");
+               }
+             return true;
+           }
+
+
+       }
+
       if (dump_enabled_p ())
        {
          dump_generic_expr_loc (MSG_NOTE, vect_location, TDF_SLIM, var);

  parent reply	other threads:[~2022-03-08 17:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-40073-4@http.gcc.gnu.org/bugzilla/>
2014-04-26  7:00 ` glisse at gcc dot gnu.org
2015-06-12  9:56 ` alalaw01 at gcc dot gnu.org
2015-06-12 10:08 ` pinskia at gcc dot gnu.org
2015-06-12 11:39 ` alalaw01 at gcc dot gnu.org
2015-06-12 12:01 ` glisse at gcc dot gnu.org
2022-03-08 17:25 ` law at gcc dot gnu.org [this message]
2009-05-08 16:57 [Bug tree-optimization/40073] New: " meissner at linux dot vnet dot ibm dot com
2009-05-08 16:59 ` [Bug tree-optimization/40073] " meissner at linux dot vnet dot ibm dot com
2009-05-08 17:02 ` meissner at linux dot vnet dot ibm dot com
2009-05-08 17:03 ` meissner at linux dot vnet dot ibm dot com
2009-05-08 17:05 ` meissner at linux dot vnet dot ibm dot com
2009-05-08 17:06 ` meissner at linux dot vnet dot ibm dot com
2009-05-08 20:39 ` rguenth at gcc dot gnu dot org

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=bug-40073-4-Uc8zRL4aDC@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).