public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
Date: Mon, 07 Feb 2011 16:39:00 -0000	[thread overview]
Message-ID: <bug-38644-4-IbmS0meUi5@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-38644-4@http.gcc.gnu.org/bugzilla/>

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #34 from Jeffrey A. Law <law at redhat dot com> 2011-02-07 16:27:24 UTC ---
Typically the right thing to do is to block all memory motions across a change
in the stack pointer.    It's somewhat overly pessimistic, but in reality the
few motions lost aren't going to be performance critical.

In the past each backend has emitted the blockage/barrier and it typically
happened soon after the port was converted to use RTL prologues/epilogues... 
That's probably the main reason why this was never fixed in the scheduler
itself -- the first couple ports emitted a blockage and after that it became
normal practice.

I would support both emitting the suitable blockage insn in the ARM backend or
adding a dependency between the stack pointer adjustment insn and all memory
insns in the scheduler.  Either is IMHO acceptable given history.  The first
would be slightly preferred during this late stage of development with the
latter being more appropriate in early stage development.


  parent reply	other threads:[~2011-02-07 16:27 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-38644-4@http.gcc.gnu.org/bugzilla/>
2010-09-30 19:16 ` sebastian.huber@embedded-brains.de
2011-01-31 21:50 ` joel at gcc dot gnu.org
2011-02-07 16:39 ` law at redhat dot com [this message]
2011-04-26 15:16 ` [Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6/4.7 " jiangning.liu at arm dot com
2011-06-27 14:30 ` rguenth at gcc dot gnu.org
2011-08-04 12:35 ` [Bug rtl-optimization/38644] [4.4/4.5/4.6/4.7 " sebastian.huber@embedded-brains.de
2011-08-05  4:00 ` ramana.r at gmail dot com
2011-08-05  6:50 ` sebastian.huber@embedded-brains.de
2011-08-09  2:08 ` jiangning.liu at arm dot com
2011-08-15  8:09 ` lingyouzeng@arimacomm-hz.cn
2011-09-06  7:46 ` sebastian.huber@embedded-brains.de
2011-09-09 13:48 ` joel at gcc dot gnu.org
2011-09-11 15:47 ` steven at gcc dot gnu.org
2011-09-12  8:48 ` sebastian.huber@embedded-brains.de
2011-09-12 15:32 ` law at redhat dot com
2011-09-12 15:37 ` rearnsha at arm dot com
2011-09-12 15:50 ` law at redhat dot com
2011-09-12 18:40 ` steven at gcc dot gnu.org
2011-09-26  8:11 ` rguenther at suse dot de
2011-10-15  8:49 ` sebastian.huber@embedded-brains.de
2011-10-24 13:09 ` sebastian.huber@embedded-brains.de
2011-10-28  7:34 ` sebastian.huber@embedded-brains.de
2011-10-29 23:29 ` davem at devkitpro dot org
2011-10-31  7:52 ` jiangning.liu at arm dot com
2011-10-31  8:34 ` mikpe at it dot uu.se
2011-10-31 10:46 ` sebastian.huber@embedded-brains.de
2011-11-04 16:53 ` jye2 at gcc dot gnu.org
2011-11-09  9:17 ` [Bug rtl-optimization/38644] [4.4/4.5/4.6 " sebastian.huber@embedded-brains.de
2011-11-16 10:33 ` liujiangning at gcc dot gnu.org
2012-01-09 16:58 ` ramana at gcc dot gnu.org
2012-03-13 14:55 ` [Bug rtl-optimization/38644] [4.5/4.6 " jakub at gcc dot gnu.org
2012-07-02 11:35 ` rguenth at gcc dot gnu.org
2012-07-31 16:29 ` [Bug rtl-optimization/38644] [4.6 " hagayg at broadcom dot com
2012-07-31 16:53 ` pinskia at gcc dot gnu.org
2012-07-31 17:37 ` hagayg at broadcom dot com
2013-04-05  3:51 ` peter at axium dot co.nz
2013-04-05  4:23 ` pinskia at gcc dot gnu.org
2013-04-05  7:15 ` sebastian.huber@embedded-brains.de
2014-02-16 10:01 ` jackie.rosen at hushmail dot com
2022-10-14  9:56 ` cvs-commit at gcc dot gnu.org
2022-10-14  9:57 ` cvs-commit at gcc dot gnu.org
2022-10-14  9:58 ` cvs-commit at gcc dot gnu.org
2022-10-14 10:00 ` cvs-commit at gcc dot gnu.org
2008-12-27 22:11 [Bug c/38644] New: " davejmurphy at me dot com
2010-08-12 10:00 ` [Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] " steven at gcc dot gnu dot org
2010-08-12 10:01 ` steven at gcc dot gnu dot org
2010-08-12 10:08 ` steven at gcc dot gnu dot org
2010-08-12 10:12 ` amonakov at gcc dot gnu dot org
2010-08-12 11:37 ` steven at gcc dot gnu dot org
2010-08-12 11:48 ` jakub at gcc dot gnu dot org
2010-08-12 12:00 ` amonakov at gcc dot gnu dot org
2010-08-12 12:04 ` rguenth at gcc dot gnu dot org
2010-08-12 12:13 ` rearnsha at gcc dot gnu dot org
2010-08-12 12:26 ` jakub at gcc dot gnu dot org
2010-08-12 12:31 ` rearnsha at gcc dot gnu dot org
2010-08-30 15:48 ` rguenth at gcc dot gnu dot org
2010-08-30 18:59 ` mikpe at it dot uu dot se

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-38644-4-IbmS0meUi5@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: 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).