public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "hpa at zytor dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/103503] New: RFE: no save registers attribute
Date: Tue, 30 Nov 2021 18:06:48 +0000	[thread overview]
Message-ID: <bug-103503-4@http.gcc.gnu.org/bugzilla/> (raw)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103503

            Bug ID: 103503
           Summary: RFE: no save registers attribute
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hpa at zytor dot com
  Target Milestone: ---
            Target: multiple

When a common assembly interrupt entry code or an equivalent hardware engine is
used to handle register saves in an interrupt routine, it may be completely
unnecessary to save and restore registers in the interrupt handler itself, even
if they would normally be clobbered.

Unfortunately [-f]call-used-reg is not supported by either
__attribute__((optimize)) nor _Pragma("GCC optimize"); otherwise that would be
a very valid solution.

Putting all interrupt handlers in a separate compilation unit is awkward at the
very best.

AVR has __attribute__((OS_{task,main})) for this purpose, but being able to do
it in general would improve interrupt/trap latency.

See also bug 38534.

Note: not saving the registers in the assembly wrapper is generally not an
option; similarly, whether or not a hardware engine can do it practically
depends on both the hardware implementation and the ABI. The RISC-V ABI, for
example, scatters clobbered and saved registers all over the register map,
which makes doing such a thing in hardware difficult.

             reply	other threads:[~2021-11-30 18:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-30 18:06 hpa at zytor dot com [this message]
2021-11-30 21:00 ` [Bug target/103503] " pinskia at gcc dot gnu.org
2021-11-30 21:02 ` pinskia at gcc dot gnu.org
2021-11-30 21:03 ` pinskia at gcc dot gnu.org
2021-11-30 21:03 ` pinskia at gcc dot gnu.org
2022-06-06 17:00 ` hpa at zytor dot com
2024-01-11  3:44 ` hjl.tools at gmail dot com
2024-01-27 12:19 ` cvs-commit at gcc dot gnu.org
2024-05-15 16:17 ` hpa at zytor dot com

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-103503-4@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).