public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rdapp at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/111794] RISC-V: Missed SLP optimization due to mask mode precision
Date: Mon, 16 Oct 2023 07:56:51 +0000	[thread overview]
Message-ID: <bug-111794-4-XEpXmCTssc@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-111794-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #5 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Disregarding the reasons for the precision adjustment, for this case here, we
seem to fail at:

  /* We do not handle bit-precision changes.  */
  if ((CONVERT_EXPR_CODE_P (code)
       || code == VIEW_CONVERT_EXPR)
      && ((INTEGRAL_TYPE_P (TREE_TYPE (scalar_dest))
           && !type_has_mode_precision_p (TREE_TYPE (scalar_dest)))
          || (INTEGRAL_TYPE_P (TREE_TYPE (op))
              && !type_has_mode_precision_p (TREE_TYPE (op))))
      /* But a conversion that does not change the bit-pattern is ok.  */
      && !(INTEGRAL_TYPE_P (TREE_TYPE (scalar_dest))
           && INTEGRAL_TYPE_P (TREE_TYPE (op))
           && (TYPE_PRECISION (TREE_TYPE (scalar_dest))
               > TYPE_PRECISION (TREE_TYPE (op)))
           && TYPE_UNSIGNED (TREE_TYPE (op))))
    {
      if (dump_enabled_p ())
        dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
                         "type conversion to/from bit-precision "
                         "unsupported.\n");
      return false;
    }

for the expression
 patt_156 = (<signed-boolean:1>) _2;
where _2 (op) is of type _Bool (i.e. TYPE_MODE QImode) and patt_156
(scalar_dest) is signed-boolean:1.  In that case the mode's precision (8) does
not match the type's precision (1) for both op and _scalar_dest.

The second part of the condition I don't fully get.  When does a conversion
change the bit pattern?  When the source has higher precision than the dest we
would need to truncate which we probably don't want.  When the dest has higher
precision that's considered ok?  What about equality?

If both op and dest have precision 1 the padding could differ (or rather the 1
could be at different positions) but do we even support that?  In other words,
could we relax the condition to TYPE_PRECISION (TREE_TYPE (scalar_dest)) >=
TYPE_PRECISION (TREE_TYPE (op)) (>= instead of >)?

FWIW bootstrap and testsuite unchanged with >= instead of > on x86, aarch64 and
power10 but we might not have a proper test for that?

  parent reply	other threads:[~2023-10-16  7:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-13  7:41 [Bug c/111794] New: " juzhe.zhong at rivai dot ai
2023-10-13  7:47 ` [Bug c/111794] " juzhe.zhong at rivai dot ai
2023-10-13  7:51 ` juzhe.zhong at rivai dot ai
2023-10-13  8:13 ` rguenth at gcc dot gnu.org
2023-10-13  8:17 ` rdapp at gcc dot gnu.org
2023-10-16  7:56 ` rdapp at gcc dot gnu.org [this message]
2023-10-16  8:50 ` rguenther at suse dot de
2023-10-16  9:05 ` rdapp at gcc dot gnu.org
2023-10-16  9:29 ` rguenther at suse dot de
2023-10-16  9:58 ` rdapp at gcc dot gnu.org
2023-10-16 14:23 ` rdapp at gcc dot gnu.org
2023-10-23 16:44 ` [Bug tree-optimization/111794] " cvs-commit at gcc dot gnu.org
2023-11-01  2:31 ` juzhe.zhong at rivai dot ai

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-111794-4-XEpXmCTssc@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).