public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/38434] [4.4 Regression] speed regression with hand-unrolled matmul Date: Sun, 07 Dec 2008 12:41:00 -0000 [thread overview] Message-ID: <20081207124012.7158.qmail@sourceware.org> (raw) In-Reply-To: <bug-38434-10391@http.gcc.gnu.org/bugzilla/> ------- Comment #4 from rguenth at gcc dot gnu dot org 2008-12-07 12:40 ------- There is one thing that is on my list to investigate. This is how the following impacts hardware prefetchers: <bb 2>: pretmp.34_33 = (*b_13(D))[6]; pretmp.34_62 = (*b_13(D))[7]; pretmp.34_88 = (*b_13(D))[8]; pretmp.37_92 = (*b_13(D))[0]; pretmp.39_95 = (*b_13(D))[1]; pretmp.39_97 = (*b_13(D))[2]; pretmp.39_99 = (*b_13(D))[3]; pretmp.39_101 = (*b_13(D))[4]; pretmp.39_103 = (*b_13(D))[5]; D.1523_164 = (*a_9(D))[0]; D.1526_163 = D.1523_164 * pretmp.37_92; D.1528_194 = (*a_9(D))[3]; D.1531_192 = D.1528_194 * pretmp.39_95; D.1532_191 = D.1526_163 + D.1531_192; D.1534_189 = (*a_9(D))[6]; ... that is, should we try to schedule memory loads and stores to be sequential? It would be interesting to measure the difference in manually unrolled code with optimal ordering and the ordering generated by the compiler during unrolling. Other than that, the above (all loads of b before all uses) certaily increases register pressure for i?86 too much so you get spills: flds 24(%ecx) fstps -24(%ebp) flds 28(%ecx) fstps -20(%ebp) flds 32(%ecx) fstps -16(%ebp) flds (%ecx) flds 4(%ecx) flds 8(%ecx) flds 12(%ecx) fstps -12(%ebp) ... and the RTL level doesn't know enough about aliasing to do anything about that. -fschedule-insns manages to improve things somewhat again - but certainly scheduling of loads/stores at the tree level would be nice (re-assoc only schedules registers). In the end this shouldn't be a regression - maybe the early unrolling of the innermost loop we do changes things enough though. It is interesting that before PRE the loads from b are in-order, but PRE insertion places them out-of-order. Huh. Because we iterate over antic expressions. -- rguenth at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- GCC target triplet| |i?86-*-* Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38434
next prev parent reply other threads:[~2008-12-07 12:41 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-12-07 11:35 [Bug rtl-optimization/38434] New: " tkoenig at gcc dot gnu dot org 2008-12-07 11:36 ` [Bug rtl-optimization/38434] " tkoenig at gcc dot gnu dot org 2008-12-07 11:56 ` tkoenig at gcc dot gnu dot org 2008-12-07 12:26 ` tkoenig at gcc dot gnu dot org 2008-12-07 12:41 ` rguenth at gcc dot gnu dot org [this message] 2008-12-09 19:31 ` mmitchel at gcc dot gnu dot org 2008-12-10 13:40 ` steven at gcc dot gnu dot org 2009-01-31 14:36 ` bonzini at gnu dot org 2009-02-04 12:02 ` [Bug rtl-optimization/38434] big performance boost from 4.3's -O3 vs. -O2 (in any version) on 3x3 matmul bonzini at gnu dot 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=20081207124012.7158.qmail@sourceware.org \ --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).