public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "amker at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/29256] [4.9/5/6 regression] loop performance regression Date: Thu, 13 Aug 2015 02:11:00 -0000 [thread overview] Message-ID: <bug-29256-4-naOFQudfRo@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-29256-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 --- Comment #60 from amker at gcc dot gnu.org --- (In reply to Bill Schmidt from comment #59) > (In reply to rguenther@suse.de from comment #57) > > > > It's been a long time since I've done SPEC measuring with/without > > -funroll-loops (or/and -fpeel-loops). Note that these flags have > > secondary effects as well: > > > > toplev.c: flag_web = flag_unroll_loops || flag_peel_loops; > > toplev.c: flag_rename_registers = flag_unroll_loops || flag_peel_loops; > > We don't have a lot of data yet, but we have seen several examples in SPEC > and other benchmarks where turning on -funroll-loops is helpful, but should > be much more helpful -- in many cases performance improves with a much > higher unroll factor. However, the effectiveness of unrolling is very much > tied up with these issues in IVOPTS, where we currently end up with too many > separate base registers for IVs. As we increase the unroll factor, we By this, do you mean too many candidates are chosen? Or the issue just like this PR describes? Thanks. > eventually hit this as a limiting factor, so fixing this IVOPTS issue would > be very helpful for POWER. > > As a side note, with -fprofile-use a GIMPLE unroller could peel and unroll > hot loop traces in loops that would otherwise be too complex to unroll. > I.e., if there is a single hot trace through a loop, you can do tail > duplication on the trace to force it into superblock form, and then peel and > unroll that superblock while falling into the original loop if the trace is > left. Complete unrolling and unrolling by a factor are both possible. I > don't know of specific benchmarks that would be helped by this, though. > > (An RTL unroller could do this as well, but it seems much more natural and > implementable in GIMPLE.)
next prev parent reply other threads:[~2015-08-13 2:11 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-29256-4@http.gcc.gnu.org/bugzilla/> 2011-06-27 13:58 ` [Bug middle-end/29256] [4.3/4.4/4.5/4.6/4.7 " rguenth at gcc dot gnu.org 2012-01-12 12:28 ` [Bug target/29256] [4.4/4.5/4.6/4.7 " rguenth at gcc dot gnu.org 2012-03-13 14:23 ` [Bug target/29256] [4.5/4.6/4.7/4.8 " jakub at gcc dot gnu.org 2012-07-02 12:25 ` rguenth at gcc dot gnu.org 2013-04-12 15:17 ` [Bug target/29256] [4.7/4.8/4.9 " jakub at gcc dot gnu.org 2013-12-09 4:50 ` law at redhat dot com 2014-06-12 13:45 ` [Bug target/29256] [4.7/4.8/4.9/4.10 " rguenth at gcc dot gnu.org 2014-12-19 13:28 ` [Bug target/29256] [4.8/4.9/5 " jakub at gcc dot gnu.org 2015-04-07 17:36 ` law at redhat dot com 2015-04-08 7:20 ` rguenther at suse dot de 2015-05-19 17:51 ` [Bug target/29256] [4.8/4.9/5/6 " law at redhat dot com 2015-05-20 2:21 ` amker at gcc dot gnu.org 2015-05-20 12:45 ` wschmidt at gcc dot gnu.org 2015-06-23 8:22 ` rguenth at gcc dot gnu.org 2015-06-26 19:59 ` [Bug target/29256] [4.9/5/6 " jakub at gcc dot gnu.org 2015-06-26 20:29 ` jakub at gcc dot gnu.org 2015-08-11 18:36 ` wschmidt at gcc dot gnu.org 2015-08-12 7:12 ` rguenther at suse dot de 2015-08-12 7:34 ` amker at gcc dot gnu.org 2015-08-12 13:24 ` wschmidt at gcc dot gnu.org 2015-08-13 2:11 ` amker at gcc dot gnu.org [this message] 2015-08-13 3:28 ` wschmidt at gcc dot gnu.org 2015-08-13 5:01 ` amker at gcc dot gnu.org 2021-05-14 9:45 ` [Bug target/29256] [9/10/11/12 " jakub at gcc dot gnu.org 2021-06-01 8:04 ` rguenth at gcc dot gnu.org 2022-05-27 9:33 ` [Bug target/29256] [10/11/12/13 " rguenth at gcc dot gnu.org 2022-06-28 10:29 ` jakub at gcc dot gnu.org 2023-07-07 10:28 ` [Bug target/29256] [11/12/13/14 " rguenth at gcc dot gnu.org 2023-07-15 7:57 ` pinskia at gcc dot gnu.org 2023-07-17 8:29 ` 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-29256-4-naOFQudfRo@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).