public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Eric Botcazou <ebotcazou@libertysurf.fr> To: ebotcazou@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: optimization/9319: slower code generated for simple loop on linux Date: Tue, 21 Jan 2003 23:16:00 -0000 [thread overview] Message-ID: <20030121231601.17596.qmail@sources.redhat.com> (raw) The following reply was made to PR optimization/9319; it has been noted by GNATS. From: Eric Botcazou <ebotcazou@libertysurf.fr> To: Richard Henderson <rth@redhat.com> Cc: Amnon Cohen <amnon_cohen@yahoo.com>, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: optimization/9319: slower code generated for simple loop on linux Date: Wed, 22 Jan 2003 00:09:52 +0100 > I don't think it's worth much time. The only way to Really Fix > this is to move to CFG-based loop analysis. Yes, and the pessimization is a direct effect of the patch, not a mere si= de=20 effect. Before, loops such as =09top: =09 /* empty */ =09body: =09 if (!cond) goto end; =09 statement; =09 goto top; =09end: were rotated, identically to canonical loops such as =09top: =09 if (!cond) goto end; =09body: =09 statement; =09 goto top; =09end: into =09 goto first; =09top: =09 statement; =09first: =09 if (cond) goto top; Now the patch explicitly forbids that, in order to preserve the unrolling= =20 pass: ! We rely on the presence of NOTE_INSN_LOOP_END_TOP_COND to mark ! the end of the entry condtional. Without this, our lexical scan ! can't tell the difference between an entry conditional and a ! body conditional that exits the loop. Mistaking the two means ! that we can misplace the NOTE_INSN_LOOP_CONT note, which can=20 ! screw up loop unrolling. Would you support relaxing the code when unrolling is disabled, in order = to=20 recover the optimization loss in that case ? --=20 Eric Botcazou
next reply other threads:[~2003-01-21 23:16 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-01-21 23:16 Eric Botcazou [this message] -- strict thread matches above, loose matches on Subject: below -- 2003-04-16 7:09 ebotcazou 2003-01-22 2:06 Richard Henderson 2003-01-17 9:35 ebotcazou 2003-01-17 3:36 Richard Henderson 2003-01-16 19:16 Eric Botcazou 2003-01-16 13:36 Amnon Cohen 2003-01-16 11:58 ebotcazou 2003-01-15 10:16 amnon_cohen
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=20030121231601.17596.qmail@sources.redhat.com \ --to=ebotcazou@libertysurf.fr \ --cc=ebotcazou@gcc.gnu.org \ --cc=gcc-prs@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).