public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "mmitchel at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/17863] [4.0/4.1 Regression] threefold performance loss, not inlining as much
Date: Mon, 31 Oct 2005 00:37:00 -0000	[thread overview]
Message-ID: <20051031003755.10030.qmail@sourceware.org> (raw)
In-Reply-To: <bug-17863-2109@http.gcc.gnu.org/bugzilla/>



------- Comment #27 from mmitchel at gcc dot gnu dot org  2005-10-31 00:37 -------
It seems unlikely to me that this is going to be release-critical, so I've
downgraded it to P4.

Our inlining heuristics are notoriously easy to perturb.  Probably, to do
substantially better, we'll need a more sophisticated cost model; or, as Jan
suggests, actually try inlining things see how much that helps.  I'm absolutely
certain that for every release we'll have at least one program that was inlined
worse than the previous release; the question is how we're doing overall, and
whether we're being particularly stupid.  So, I think the question is if we're
actually being particularly stupid on this test case.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863


  parent reply	other threads:[~2005-10-31  0:37 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-17863-2109@http.gcc.gnu.org/bugzilla/>
2005-10-29 22:36 ` steven at gcc dot gnu dot org
2005-10-31  0:37 ` mmitchel at gcc dot gnu dot org [this message]
2005-10-31 18:36 ` hubicka at gcc dot gnu dot org
2005-10-31 19:15 ` hubicka at gcc dot gnu dot org
2005-11-24 17:34 ` [Bug tree-optimization/17863] [4.0/4.1/4.2 " phython at gcc dot gnu dot org
2006-02-09 23:14 ` [Bug tree-optimization/17863] [4.0/4.1/4.2 Regression] performance loss (not inlining as much??) steven at gcc dot gnu dot org
2006-03-11  3:20 ` mmitchel at gcc dot gnu dot org
2007-01-18  3:06 ` [Bug tree-optimization/17863] [4.0/4.1/4.2/4.3 " gdr at gcc dot gnu dot org
2007-01-21 21:49 ` pinskia at gcc dot gnu dot org
2007-02-14  9:23 ` mmitchel at gcc dot gnu dot org
2007-12-18 20:02 ` steven at gcc dot gnu dot org
2008-01-30 17:35 ` hubicka at gcc dot gnu dot org
2008-01-30 18:27 ` hubicka at gcc dot gnu dot org
2008-01-30 18:34 ` hubicka at gcc dot gnu dot org
2008-01-30 20:41 ` stevenb dot gcc at gmail dot com
2008-01-31  1:13 ` hubicka at ucw dot cz
2008-01-31 10:00 ` rguenther at suse dot de
2008-02-01 16:48 ` hubicka at gcc dot gnu dot org
2008-02-01 17:46 ` amacleod at redhat dot com
2008-02-01 22:34 ` [Bug tree-optimization/17863] [4.0/4.1/4.2/4.3 Regression] performance loss (TER register presure and inlining limits problems) hubicka at gcc dot gnu dot org
2008-02-01 22:45 ` hubicka at ucw dot cz
2008-02-01 22:55 ` [Bug tree-optimization/17863] [4.0/4.1/4.2/4.3 Regression] performance loss (register pressure due to RA sucking " pinskia at gcc dot gnu dot org
2008-07-04 16:34 ` [Bug tree-optimization/17863] [4.2/4.3/4.4 Regression] performance loss performance loss (TER register presure " jsm28 at gcc dot gnu dot org
2009-02-08 11:50 ` [Bug tree-optimization/17863] [4.2/4.3/4.4 Regression] " hubicka at gcc dot gnu dot org
2009-03-31 16:20 ` [Bug tree-optimization/17863] [4.3/4.4/4.5 " jsm28 at gcc dot gnu dot org
2009-08-04 12:27 ` rguenth at gcc dot gnu dot org
2009-12-28 15:40 ` steven at gcc dot gnu dot org
2010-03-21 12:13 ` steven at gcc dot gnu dot org
2004-10-06 15:33 [Bug tree-optimization/17863] New: threefold performance loss kunert at physik dot tu-dresden dot de
2005-03-02 11:35 ` [Bug tree-optimization/17863] [4.0/4.1 Regression] threefold performance loss, not inlining as much steven at gcc dot gnu dot org
2005-03-02 11:36 ` steven at gcc dot gnu dot org
2005-03-05 18:49 ` steven at gcc dot gnu dot org
2005-03-05 19:03 ` rguenth at tat dot physik dot uni-tuebingen dot de
2005-04-21  5:06 ` mmitchel at gcc dot gnu dot org
2005-06-27  4:54 ` dank at kegel dot com
2005-06-27  6:38 ` steven at gcc dot gnu dot org
2005-06-30 22:16 ` danalis at cis dot udel dot edu
2005-06-30 22:24 ` danalis at cis dot udel dot edu
2005-07-01  3:44 ` dank at kegel dot com
2005-07-08  1:45 ` mmitchel at gcc dot gnu dot org
2005-09-27 16:25 ` mmitchel at gcc dot 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=20051031003755.10030.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: link
Be 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).