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