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 tree-optimization/102540] [12 Regression] Dead Code Elimination Regression at -O3 since r12-476-gd846f225c25c5885 Date: Thu, 30 Sep 2021 12:50:00 +0000 [thread overview] Message-ID: <bug-102540-4-d9HCXs3FMk@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-102540-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102540 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aldyh at gcc dot gnu.org, | |amacleod at redhat dot com Blocks| |85316 Version|unknown |12.0 --- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- FRE1 has the following difference, simplifying the (unsigned int) truncation. <bb 2> : a.0_1 = a; _2 = (unsigned int) a.0_1; b = _2; - c_10 = (long int) _2; + _6 = a.0_1 & 4294967295; + c_10 = _6; if (c_10 != 0) goto <bb 3>; [INV] else where the EVRP which now uses ranger retains (diff from GCC 11 to trunk): <bb 2> : a.0_1 = a; _2 = (unsigned int) a.0_1; b = _2; - c_10 = (long int) _2; + _6 = a.0_1 & 4294967295; + c_10 = _6; if (c_10 != 0) goto <bb 3>; [INV] else - goto <bb 4>; [INV] + goto <bb 6>; [INV] <bb 3> : _4 = c_10 + 1; iftmp.2_12 = 2 / _4; + if (iftmp.2_12 != 0) + goto <bb 4>; [INV] + else + goto <bb 6>; [INV] <bb 4> : + if (_2 == 0) + goto <bb 5>; [INV] + else + goto <bb 6>; [INV] + + <bb 5> : + foo (); + + <bb 6> : a = 0; return 0; after EVRP we have + # RANGE [0, 4294967295] NONZERO 4294967295 c_10 = _6; ... + # RANGE [2, 4294967296] NONZERO 8589934591 _4 = c_10 + 1; + # RANGE [0, 1] NONZERO 1 iftmp.2_12 = 2 / _4; if (iftmp.2_12 != 0) what we did in GCC 11 is simplified the following check <bb 4> : if (_2 == 0) goto <bb 5>; [INV] else goto <bb 6>; [INV] based on iftmp.2_12 == [1, 1] via ranger and evrp visiting BB4 Visiting controlling predicate if (iftmp.2_12 != 0) Adding assert for iftmp.2_12 from iftmp.2_12 != 0 Intersecting long int ~[0, 0] EQUIVALENCES: { iftmp.2_12 } (1 elements) and long int [0, 1] to long int [1, 1] EQUIVALENCES: { iftmp.2_12 } (1 elements) Intersecting long int [0, 1] and long int [1, 1] to long int [1, 1] pushing new range for iftmp.2_12: long int [1, 1] EQUIVALENCES: { iftmp.2_12 } (1 elements) evrp visiting stmt if (_2 == 0) Folding statement: if (_2 == 0) Visiting conditional with predicate: if (_2 == 0) With known ranges _2: unsigned int [1, +INF] EQUIVALENCES: { _2 } (1 elements) Predicate evaluates to: 0 Folded into: if (0 != 0) that's now missing, somehow due to the folded IL if the bisect is correct. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
next prev parent reply other threads:[~2021-09-30 12:50 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-30 9:27 [Bug tree-optimization/102540] New: Dead Code Elimination Regression at -O3 (trunk vs 11.2.0) theodoridisgr at gmail dot com 2021-09-30 10:05 ` [Bug tree-optimization/102540] [12 Regression] Dead Code Elimination Regression at -O3 since r12-476-gd846f225c25c5885 marxin at gcc dot gnu.org 2021-09-30 12:50 ` rguenth at gcc dot gnu.org [this message] 2021-09-30 17:39 ` aldyh at gcc dot gnu.org 2021-10-01 21:02 ` amacleod at redhat dot com 2021-10-04 6:36 ` rguenther at suse dot de 2021-10-04 17:15 ` amacleod at redhat dot com 2021-10-05 6:19 ` rguenther at suse dot de 2021-10-05 13:59 ` amacleod at redhat dot com 2022-01-20 9:44 ` rguenth at gcc dot gnu.org 2022-01-20 14:42 ` amacleod at redhat dot com 2022-05-06 8:31 ` [Bug tree-optimization/102540] [12/13 " jakub at gcc dot gnu.org 2022-07-26 13:26 ` rguenth at gcc dot gnu.org 2022-10-13 15:29 ` cvs-commit at gcc dot gnu.org 2022-10-13 17:03 ` amacleod at redhat dot com
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-102540-4-d9HCXs3FMk@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).