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.
 >


             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).