public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "web at brolinembedded dot se" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/55757] Suboptimal interrupt prologue/epilogue for ARMv7-M (Cortex-M3)
Date: Sat, 02 Mar 2013 15:23:00 -0000 [thread overview]
Message-ID: <bug-55757-4-d9jhJ9c6X5@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-55757-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55757
Timmy Brolin <web at brolinembedded dot se> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |web at brolinembedded dot
| |se
--- Comment #7 from Timmy Brolin <web at brolinembedded dot se> 2013-03-02 15:23:11 UTC ---
(In reply to comment #2)
> If you really know that you don't need stack-alignment on an M3, then just
> remove the interrupt attribute. It really doesn't serve any other purpose on
> M-profile cores other than to cause the stack realignment.
What you suggest requires a change in the C-code depending on the processor.
That is, one piece of C-code will not compile optimally for different Cortex-M3
revisions without modifications to the C-code itself. This is not good for code
which is intended to be used on multiple platforms.
Cortex-M3 r0p0 needs the prologue/epilogue.
Cortex-M3 r1p0 has a new configuration bit called STKALIGN which when enabled
makes the prologue/epilogue unnecessary. (But the default setting is that it
still needs the prologue/epilogue)
Cortex-M3 r2p0 changed the default setting of STKALIGN so that the
prologue/epilogue are unnecessary by default.
I would suggest that the prologue/epilogue should be removed by default when
compiling for r2p0 or higher, but be kept by default for older revisions.
There should also be a compilation switch to manually enable/disable the
prologue/epilogue according to the chosen setting of STKALIGN.
Interrupts can often be time critical, so ISR entry is probably the worst
possible place for extra instructions.
next prev parent reply other threads:[~2013-03-02 15:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-20 15:04 [Bug rtl-optimization/55757] New: " freddie_chopin at op dot pl
2012-12-20 15:24 ` [Bug rtl-optimization/55757] " freddie_chopin at op dot pl
2012-12-20 16:52 ` rearnsha at gcc dot gnu.org
2012-12-20 17:08 ` freddie_chopin at op dot pl
2012-12-21 3:23 ` joey.ye at arm dot com
2012-12-21 3:32 ` joey.ye at arm dot com
2012-12-21 7:09 ` freddie_chopin at op dot pl
2013-03-02 15:23 ` web at brolinembedded dot se [this message]
2023-11-28 23:10 ` yann at poupet dot eu
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-55757-4-d9jhJ9c6X5@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).