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