public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: "J.D." <jodaman@cegt201.bradley.edu>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
Subject: Re: c/4134: inline assembly - gcc fails to work around register pressure
Date: Thu, 25 Apr 2002 06:56:00 -0000 [thread overview]
Message-ID: <20020425135600.31096.qmail@sources.redhat.com> (raw)
The following reply was made to PR c/4134; it has been noted by GNATS.
From: "J.D." <jodaman@cegt201.bradley.edu>
To: rth@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
jodaman@cegt201.bradley.edu, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:
Subject: Re: c/4134: inline assembly - gcc fails to work around register pressure
Date: Thu, 25 Apr 2002 08:50:27 -0500
In retrospect, egcs failed to avoid using the clobbered
register, just as you suggested. Thus, what I initially
interpreted as a bug in the later gcc versions now seems
better classified as the lack of a feature.
A compiler could work around the register pressure by
copying the 32-bit integer in memory to the stack. Thus,
an offset to the stack pointer could serve for the memory
parameter, instead of a separate address register.
Given the ease of manually copying input memory parameters
from any memory location to the local stack in C, an
automatic feature may be primarily useful to less
experienced or sleep-deprived programmers under specific
conditions. Instead of implementing an automatic feature, a
satisfactory improvement might be realized by simply
adding to the documentation that gcc will not automatically
copy memory parameters to the stack in an effort to work
around scarce registers. An automatic copy-memory-to
stack-under-pressure feature may sometimes need to be
disabled anyway.
Most convenient would be an automatic feature that issues a
warning whenever utilized, but that works around the scarce
registers and still creates working code (for the usual
case). A programmer may then remove the warning by an
explicit copy to the loca
explicit attention will be required.
rth@gcc.gnu.org wrote:
>
> Synopsis: inline assembly - gcc fails to work around register pressure
>
> State-Changed-From-To: open->closed
> State-Changed-By: rth
> State-Changed-When: Tue Apr 23 01:18:11 2002
> State-Changed-Why:
> Not a bug. You really have run out of registers.
>
> Your ifdef BUG example requires 7 registers: 3 for
> each of the "r" inputs, 1 for the address of the
> input memory parameter, and 3 are clobbered and thus
> cannot be used.
>
> The i386 has 8 registers one is reserved for the stack pointer, and one is reserved for the frame pointer (at least
> without -fomit-frame-pointer), leaving only 6, one short
> of the required 7.
>
> As a guess, egcs failed to properly not use one of the
> registers marked clobbered.
>
next reply other threads:[~2002-04-25 13:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-25 6:56 J.D. [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-04-23 1:18 rth
2001-08-27 2:16 jodaman
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=20020425135600.31096.qmail@sources.redhat.com \
--to=jodaman@cegt201.bradley.edu \
--cc=gcc-prs@gcc.gnu.org \
--cc=nobody@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).