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/58417] Incorrect optimization in SCEV const-prop Date: Mon, 16 Sep 2013 11:28:00 -0000 [thread overview] Message-ID: <bug-58417-4-ymKRTazNz4@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-58417-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58417 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebpop at gmail dot com --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- SCCP does "constant propagation" each SSA name at the beginning which is where it replaces sum_23 with 0. It ends up there through interpret_condition_phi with respect to loop 0 which analyzes the scalar evolution of sum_11 in loop 1 to 0 because it simply passes down the loop #2 0x0000000000c417c2 in interpret_condition_phi (loop=0x7ffff6d13320, condition_phi=<gimple_phi 0x7ffff6e48200>) at /space/rguenther/src/svn/trunk/gcc/tree-scalar-evolution.c:1585 1585 (loop, PHI_ARG_DEF (condition_phi, i)); (gdb) l 1580 res = chrec_dont_know; 1581 break; 1582 } 1583 1584 branch_chrec = analyze_scalar_evolution 1585 (loop, PHI_ARG_DEF (condition_phi, i)); 1586 1587 res = chrec_merge (res, branch_chrec); 1588 } that is, this is a loop-closed PHI node, not a "condition PHI". The SSA edge following code seems to have the same issues. That is, if an edge into a PHI is coming from an inner loop then we need to compute the evolution of the PHI arg with respect to that (the definition loop) and compute the overall effects for that inner loop before using the result. Hm, but analyzing sum_11 in loop1 results in _10 = {0, +, _9}_1 prevsum_21 = {0, +, _9}_1 and thus sum_11 = _10 - prevsum_21 = 0. Hmm. I don't think that's a valid CHREC (_9 is defined in loop 1). And indeed resolve_mixers will drop those to scev_not_known. But it doesn't get to that as we first cancel the thing by doing the minus ... So, Index: tree-scalar-evolution.c =================================================================== --- tree-scalar-evolution.c (revision 202619) +++ tree-scalar-evolution.c (working copy) @@ -1699,6 +1699,8 @@ interpret_rhs_expr (struct loop *loop, g chrec2 = analyze_scalar_evolution (loop, rhs2); chrec1 = chrec_convert (type, chrec1, at_stmt); chrec2 = chrec_convert (type, chrec2, at_stmt); + chrec1 = resolve_mixers (loop, chrec1); + chrec2 = resolve_mixers (loop, chrec2); res = chrec_fold_minus (type, chrec1, chrec2); break; fixes this, but ... I suppose we need to do that for each binary/ternary op and chrec (or just those that call chrec_fold_{plus,minus}). That said, we cannot hope on such SSA names canceling themselves out as they may not refer to the same actual value.
next prev parent reply other threads:[~2013-09-16 11:28 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-09-13 20:21 [Bug c++/58417] New: Incorrect optimization mirzayanovmr at gmail dot com 2013-09-13 21:40 ` [Bug tree-optimization/58417] " glisse at gcc dot gnu.org 2013-09-16 8:38 ` [Bug tree-optimization/58417] Incorrect optimization in SCEV const-prop rguenth at gcc dot gnu.org 2013-09-16 8:40 ` rguenth at gcc dot gnu.org 2013-09-16 11:28 ` rguenth at gcc dot gnu.org [this message] 2013-09-16 11:59 ` rguenth at gcc dot gnu.org 2013-09-17 9:51 ` rguenth at gcc dot gnu.org 2013-09-18 12:31 ` rguenth at gcc dot gnu.org 2013-09-18 12:32 ` rguenth at gcc dot gnu.org 2013-09-20 10:19 ` rguenth at gcc dot gnu.org 2013-09-20 17:50 ` rguenth 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-58417-4-ymKRTazNz4@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).