public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/95582] [11 Regression] LTO lean + PGO bootstrap is broken in Ada Date: Fri, 11 Dec 2020 08:23:34 +0000 [thread overview] Message-ID: <bug-95582-4-JOD42xFEds@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-95582-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> --- OK, so we recognize _22 = (boolean) _21 as bool pattern (convert from 1-bit bool to 8-bit ada bool). vect_recog_bool_pattern has some early-outs like if (CONVERT_EXPR_CODE_P (rhs_code) || rhs_code == VIEW_CONVERT_EXPR) { if (! INTEGRAL_TYPE_P (TREE_TYPE (lhs)) || TYPE_PRECISION (TREE_TYPE (lhs)) == 1) return NULL; which might be trying to rule out VECT_SCALAR_BOOLEAN_TYPE_P lhs. At least we're doing vectype = get_vectype_for_scalar_type (vinfo, TREE_TYPE (lhs)); if (vectype == NULL_TREE) return NULL; on it which will never return a VECTOR_BOOLEAN_TYPE_P and thus necessarily trip the assert in vect_init_pattern_stmt [in case the stmt is supposed to use mask precision]. Note the pattern as recognized doesn't necessarily do anything wrong - but the meta recorded is inconsistent with it: note: using boolean precision 16 for _21 = _11 != _12; note: using boolean precision 16 for _22 = (boolean) _21; note: using boolean precision 16 for _7 = PHI <0(7), _22(5), 1(9)> the function we trip on here doesn't contain any useful vectorization opportunity but clearly the "pattern" is to have a "bool" compare converted to Ada "data bool". The conversion at hand is exposed by phiopt doing - if (_11 != _12) - goto <bb 6>; [66.00%] - else - goto <bb 7>; [34.00%] - - <bb 6> [count: 0]: + _21 = _11 != _12; + _22 = (boolean) _21; - <bb 7> [count: 4858]: - # _7 = PHI <0(2), 0(3), 1(4), 0(5), 1(6)> + <bb 6> [count: 4858]: + # _7 = PHI <0(2), 0(3), 1(4), _22(5)> where phiopt could have used the PHI arguments boolean type rather than the LTO middle-end one also avoiding this ICE. The interesting fact is that the bool conversion is not useless (it changes precision) but the IL verifier allows both types to be the result of the _11 != _12 compare (so we could add some fold pattern consuming those conversions as well). But this might make constructing a Ada testcase (with -flto of course) possible by making sure there's a phiopt value-replacement opportunity (we don't realize those "early" before LTO writeout) feeding bool memory (so we have a real BB vectorization opportunity as well). Now, I'm going to test diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c index f2ce75aac3e..bf57c49bf04 100644 --- a/gcc/tree-vect-patterns.c +++ b/gcc/tree-vect-patterns.c @@ -4067,7 +4067,7 @@ vect_recog_bool_pattern (vec_info *vinfo, || rhs_code == VIEW_CONVERT_EXPR) { if (! INTEGRAL_TYPE_P (TREE_TYPE (lhs)) - || TYPE_PRECISION (TREE_TYPE (lhs)) == 1) + || VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (lhs))) return NULL; vectype = get_vectype_for_scalar_type (vinfo, TREE_TYPE (lhs)); if (vectype == NULL_TREE) which will definitely solve this instance of the ICE but of course other fallout is unknown. I'm leaving the PHI-OPT "optimization" opportunity to the Ada folks if they care. Likewise crafting a testcase from the above [I'm going to think again about how to funnel non-standard bool types to the GIMPLE FE - likely an additional attribute]
next prev parent reply other threads:[~2020-12-11 8:23 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-08 16:40 [Bug bootstrap/95582] New: " marxin at gcc dot gnu.org 2020-06-09 6:59 ` [Bug bootstrap/95582] " rguenth at gcc dot gnu.org 2020-06-09 7:31 ` marxin at gcc dot gnu.org 2020-06-09 8:10 ` marxin at gcc dot gnu.org 2020-06-09 8:14 ` marxin at gcc dot gnu.org 2020-06-09 8:25 ` marxin at gcc dot gnu.org 2020-06-09 8:47 ` rguenth at gcc dot gnu.org 2020-06-09 8:52 ` rguenth at gcc dot gnu.org 2020-06-09 9:40 ` ebotcazou at gcc dot gnu.org 2020-06-09 10:38 ` rguenther at suse dot de 2020-06-09 11:23 ` ebotcazou at gcc dot gnu.org 2020-08-27 12:40 ` marxin at gcc dot gnu.org 2020-08-27 12:55 ` rguenth at gcc dot gnu.org 2020-08-27 13:24 ` marxin at gcc dot gnu.org 2020-10-02 13:05 ` marxin at gcc dot gnu.org 2020-10-07 10:02 ` rguenth at gcc dot gnu.org 2020-10-07 11:42 ` rguenth at gcc dot gnu.org 2020-10-07 12:38 ` rguenth at gcc dot gnu.org 2020-12-07 10:05 ` marxin at gcc dot gnu.org 2020-12-10 14:01 ` rguenth at gcc dot gnu.org 2020-12-10 14:21 ` ebotcazou at gcc dot gnu.org 2020-12-11 8:23 ` rguenth at gcc dot gnu.org [this message] 2020-12-11 9:10 ` cvs-commit at gcc dot gnu.org 2020-12-11 9:49 ` rguenth at gcc dot gnu.org 2021-01-06 9:21 ` cvs-commit at gcc dot gnu.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-95582-4-JOD42xFEds@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).