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 lto/56295] [4.8 Regression] Missed optimization with LTO Date: Tue, 12 Feb 2013 12:21:00 -0000 [thread overview] Message-ID: <bug-56295-4-24FjZKph8l@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-56295-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56295 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Last reconfirmed| |2013-02-12 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-12 12:21:19 UTC --- With -O3 -flto the loop is not peeled before loop-distribution and thus the inner loop is identified as memcpy. With -O3 the inner loop is peeled. That is because at cunrolli we see with -flto Statement _8 = b[i_1][j_2]; is probably executed at most 3 (bounded by 3) + 1 times in loop 2. vs. without -flto Statement _8 = b[i_1][j_2]; is executed at most 3 (bounded by 3) + 1 times in loop 1. With -flto we run into /* For arrays at the end of the structure, we are not guaranteed that they do not really extend over their declared size. However, for arrays of size greater than one, this is unlikely to be intended. */ if (array_at_struct_end_p (base)) { at_end = true; upper = false; for b[i_1][j_2] (where it is really a MEM[&b][i_1][j_2]). That's because array_at_struct_end_p doesn't consider MEM_REFs and we (in this case) needlessly wrap b in a MEM_REF during streaming out (so that at input time prevailing decl replacement does not change aliasing / tree code validity). We should probably undo this at streaming in time where possible. I have a patch that does this.
next prev parent reply other threads:[~2013-02-12 12:21 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-02-12 10:54 [Bug lto/56295] New: " d.g.gorbachev at gmail dot com 2013-02-12 11:02 ` [Bug lto/56295] " d.g.gorbachev at gmail dot com 2013-02-12 12:21 ` rguenth at gcc dot gnu.org [this message] 2013-02-12 14:05 ` rguenth at gcc dot gnu.org 2013-02-12 14:05 ` rguenth at gcc dot gnu.org 2013-02-12 16:27 ` d.g.gorbachev at gmail dot com 2013-02-13 11:51 ` rguenth at gcc dot gnu.org 2013-02-13 13:31 ` 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-56295-4-24FjZKph8l@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).