public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "liujiangning at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/51049] New: A regression caused by "Improve handling of conditional-branches on targets with high branch costs" Date: Wed, 09 Nov 2011 07:49:00 -0000 [thread overview] Message-ID: <bug-51049-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51049 Bug #: 51049 Summary: A regression caused by "Improve handling of conditional-branches on targets with high branch costs" Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned@gcc.gnu.org ReportedBy: liujiangning@gcc.gnu.org int f(char *i, int j) { if (*i && j!=2) return *i; else return j; } Before the check-in r180109, we have D.4710 = *i; D.4711 = D.4710 != 0; D.4712 = j != 2; D.4713 = D.4711 & D.4712; if (D.4713 != 0) goto <D.4714>; else goto <D.4715>; <D.4714>: D.4710 = *i; D.4716 = (int) D.4710; return D.4716; <D.4715>: D.4716 = j; return D.4716; After check-in r180109, we have D.4711 = *i; if (D.4711 != 0) goto <D.4712>; else goto <D.4710>; <D.4712>: if (j != 2) goto <D.4713>; else goto <D.4710>; <D.4713>: D.4711 = *i; D.4714 = (int) D.4711; return D.4714; <D.4710>: D.4714 = j; return D.4714; the code below in function fold_truth_andor makes difference, /* Transform (A AND-IF B) into (A AND B), or (A OR-IF B) into (A OR B). For sequence point consistancy, we need to check for trapping, and side-effects. */ else if (code == icode && simple_operand_p_2 (arg0) && simple_operand_p_2 (arg1)) return fold_build2_loc (loc, ncode, type, arg0, arg1); for "*i != 0" simple_operand_p(*i) returns false. Originally this is not checked by the code. Please refer to http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02445.html for discussion details. This change accidently made some benchmarks significantly improved due to some other reasons, but Michael gave the comments below. ======Michael's comment====== It's nice that it caused a benchmark to improve significantly, but that should be done via a proper analysis and patch, not as a side effect of a supposed non-change. ======End of Michael's comment====== The potential impact would be hurting other scenarios on performance. The key point is for this small case I gave RHS doesn't have side effect at all, so the optimization of changing it to AND doesn't violate C specification. ======Kai's comment====== As for the case that left-hand side has side-effects but right-hand not, we aren't allowed to do this AND/OR merge. For example 'if ((f = foo ()) != 0 && f < 24)' we aren't allowed to make this transformation. This shouldn't be that hard. We need to provide to simple_operand_p_2 an additional argument for checking trapping or not. ======End of Kai's comment====== This optimization change is blocking some other optimizations I am working on in back-ends. For example, the problem I described at http://gcc.gnu.org/ml/gcc/2011-09/msg00175.html disappeared. But it is not a proper behavior. Thanks, -Jiangning
next reply other threads:[~2011-11-09 7:37 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-11-09 7:49 liujiangning at gcc dot gnu.org [this message] 2011-11-09 7:52 ` [Bug tree-optimization/51049] " liujiangning at gcc dot gnu.org 2011-11-09 9:23 ` rguenth at gcc dot gnu.org 2023-08-03 5:12 ` pinskia 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-51049-4@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).