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);
next prev 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: linkBe 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).