public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/103860] [9/10/11 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu Date: Tue, 04 Jan 2022 09:13:18 +0000 [thread overview] Message-ID: <bug-103860-4-j4aN6DY3EA@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-103860-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103860 --- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:801b2c880c8079934ac186ea1c31f3bf4af5aef3 commit r12-6202-g801b2c880c8079934ac186ea1c31f3bf4af5aef3 Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Jan 4 10:12:17 2022 +0100 shrink-wrapping: Don't call can_get_prologue unnecessarily [PR103860] On Thu, Dec 30, 2021 at 04:08:25AM -0600, Segher Boessenkool wrote: > > The following simple patch makes sure we call can_get_prologue even after > > the last former iteration when vec is already empty and only break from > > the loop afterwards (and only if the updating of pro done because of > > !can_get_prologue didn't push anything into vec again). During the development of the above patch I've noticed that in many cases we call can_get_prologue often on the same pro again and again and again, we can have many basic blocks pushed into vec and if most of those don't require pro updates, i.e. basic_block bb = vec.pop (); if (!can_dup_for_shrink_wrapping (bb, pro, max_grow_size)) while (!dominated_by_p (CDI_DOMINATORS, bb, pro)) isn't true, then pro is can_get_prologue checked for each bb in the vec. The following simple patch just remembers which bb we've verified already and verifies again only when pro changes. Most of the patch is just reindentation. 2022-01-04 Jakub Jelinek <jakub@redhat.com> PR rtl-optimization/103860 * shrink-wrap.c (try_shrink_wrapping): Don't call can_get_prologue uselessly for blocks for which it has been called already.
next prev parent reply other threads:[~2022-01-04 9:13 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-12-29 16:08 [Bug tree-optimization/103860] New: " zhendong.su at inf dot ethz.ch 2021-12-29 17:17 ` [Bug rtl-optimization/103860] [9/10/11/12 Regression] " jakub at gcc dot gnu.org 2021-12-29 17:32 ` jakub at gcc dot gnu.org 2021-12-29 18:10 ` jakub at gcc dot gnu.org 2021-12-29 18:23 ` jakub at gcc dot gnu.org 2021-12-29 19:43 ` segher at gcc dot gnu.org 2021-12-29 19:58 ` jakub at gcc dot gnu.org 2021-12-29 20:30 ` segher at gcc dot gnu.org 2021-12-30 13:24 ` cvs-commit at gcc dot gnu.org 2021-12-30 13:39 ` [Bug rtl-optimization/103860] [9/10/11 " jakub at gcc dot gnu.org 2022-01-04 9:13 ` cvs-commit at gcc dot gnu.org [this message] 2022-01-04 13:59 ` rguenth at gcc dot gnu.org 2022-01-24 9:20 ` cvs-commit at gcc dot gnu.org 2022-01-24 9:30 ` [Bug rtl-optimization/103860] [9/10 " jakub at gcc dot gnu.org 2022-05-10 8:22 ` cvs-commit at gcc dot gnu.org 2022-05-11 6:23 ` cvs-commit at gcc dot gnu.org 2022-05-11 6:36 ` jakub 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-103860-4-j4aN6DY3EA@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).