public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/59643] New: Predictive commoning unnecessarily punts on scimark2 SOR Date: Mon, 30 Dec 2013 22:00:00 -0000 [thread overview] Message-ID: <bug-59643-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59643 Bug ID: 59643 Summary: Predictive commoning unnecessarily punts on scimark2 SOR Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org I've noticed GCC performs badly on scimark2 SOR compared to llvm 3.[34], and I believe the difference is in predictive commoning, which IMHO unnecessarily gives up on the loop. https://cmssdt.cern.ch/SDT/lxr/source/Validation/Performance/bin/SOR.c?v=Sat The inner loop is: for (j=1; j<Nm1; j++) Gi[j] = omega_over_four * (Gim1[j] + Gip1[j] + Gi[j-1] + Gi[j+1]) + one_minus_omega * Gi[j]; and the problem is that data ref doesn't know that Gim1[j] and Gip1[j] reads don't conflict with the Gi[j] write (they don't in the benchmark, but the compiler can't know that (unless -flto and some extra smart IPA analysis hints that, that is primarily a bad choice of data structures in the benchmark, instead of using array of pointers to double where each inner array is malloced separately, using two dimensional array might make it clear to the compiler there is no aliasing). When constructing components, pcom ignores read-read dependencies with offset that can't be determined, but in this case there is a write and thus all the data references are put into the same component and that component is unsuitable, because the offset can't be determined. For two writes with unknown dependencies, there is nothing that can be done, but I wonder if for the case of (suitable) write and some other read where we can't determine offset we really have to give up on both the data refs, rather than just the read. On this testcase, giving up on the Gim1[j] and Gip1[j] reads that could possibly overlap with Gi[j] write is IMHO fine, we just keep them as is and don't attempt to optimize them, and pcom doesn't optimize away writes either (or does it? then we'd need to say on the component that it shouldn't do it in that case). With the untested patch I'll attach scimark2 improved from SOR Mflops: 1135.50 (1000 x 1000) to SOR Mflops: 1617.87 (1000 x 1000)
next reply other threads:[~2013-12-30 22:00 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-12-30 22:00 jakub at gcc dot gnu.org [this message] 2013-12-30 22:02 ` [Bug tree-optimization/59643] " jakub at gcc dot gnu.org 2014-01-07 7:49 ` jakub at gcc dot gnu.org 2014-01-07 9:21 ` jakub at gcc dot gnu.org 2014-01-07 22:47 ` steven 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-59643-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).