All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Arjan van de Ven <arjanv@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [BK+PATCH] remove __constant_memcpy
Date: Thu, 17 Apr 2003 15:07:49 -0400	[thread overview]
Message-ID: <20030417190749.GF25696@gtf.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0304170903001.1530-100000@home.transmeta.com>

On Thu, Apr 17, 2003 at 09:07:45AM -0700, Linus Torvalds wrote:
> 
> On 17 Apr 2003, Arjan van de Ven wrote:
> > 
> > it can do that ANYWAY for all kinds of things.
> > We really should ask the gcc folks to add a
> > -fdontyoudareusefloatingpoint flag (well different name probably)
> 
> Well, _most_ architectures actually have that flag already. It's not 
> called -fdontyoudareusefloatingpoint on any of them, though ;)
> 
> It's most commonly called "-mno-fpu", but sh calls it "-mno-implicit-fp",
> and alpha calls it "-mno-fp-regs".
> 
> On x86, gcc doesn't have such an option, although "-mno-sse" and
> "-mno-sse2" probably come closest (and we should probably use them, but
> since older gcc's don't know about it and it hasn't been an issue yet we
> haven't).

gcc on x86 definitely wants a -fdontyoudareusefloatingpoint... The
following snippet from the -msoft-float docs isn't encouraging:

     On machines where a function returns floating point results in the
     80387 register stack, some floating point opcodes may be emitted
     even if `-msoft-float' is used.
[yes, I realize it's an ABI constraint in this case, but IMO it's also
indicative in general of the difficulty in getting gcc to _never_
generate fp opcodes on x86, now or in the future]

Anyway, if you wanna play it safe WRT gcc future, the following
patch works.

-mno-3dnow is probably over-paranoia, because (IIRC) it doesn't contain
any integer instructions, but maybe I'm wrong.  It can't hurt... :)


===== arch/i386/Makefile 1.49 vs edited =====
--- 1.49/arch/i386/Makefile	Thu Apr  3 14:24:40 2003
+++ edited/arch/i386/Makefile	Thu Apr 17 14:55:34 2003
@@ -27,6 +27,9 @@
 # prevent gcc from keeping the stack 16 byte aligned
 CFLAGS += $(call check_gcc,-mpreferred-stack-boundary=2,)
 
+# force gcc to always use general registers (only)
+CFLAGS += $(call check_gcc,-mno-mmx -mno-sse -mno-sse2 -mno-3dnow,)
+
 align := $(subst -functions=0,,$(call check_gcc,-falign-functions=0,-malign-functions=0))
 
 cflags-$(CONFIG_M386)		+= -march=i386

  reply	other threads:[~2003-04-17 18:55 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-17  0:57 [BK+PATCH] remove __constant_memcpy Jeff Garzik
2003-04-17  1:04 ` Jeff Garzik
2003-04-17  2:06 ` Linus Torvalds
2003-04-17  8:46   ` Arjan van de Ven
2003-04-17  9:02     ` Roman Zippel
2003-04-17  9:04       ` Arjan van de Ven
2003-04-17  9:11         ` Jakub Jelinek
2003-04-17 16:07     ` Linus Torvalds
2003-04-17 19:07       ` Jeff Garzik [this message]
2003-04-17 19:19       ` Jeff Garzik
2003-04-17 19:54         ` Linus Torvalds
2003-04-17 23:49           ` Jeff Garzik
2003-04-17 23:52             ` Jeff Garzik
2003-04-17 23:59             ` Linus Torvalds
2003-04-18  0:29               ` H. Peter Anvin
2003-04-18  9:06             ` Arjan van de Ven
2003-04-18 14:31             ` Timothy Miller
2003-04-18 15:07               ` Richard B. Johnson
2003-04-17 22:58         ` J.A. Magallon
2003-04-17 23:10           ` Jeff Garzik
2003-04-17 13:17 ` Alan Cox
2003-04-17 13:17 ` Alan Cox
2003-04-17 14:32   ` Jeff Garzik
2003-04-17 14:40     ` Jeff Garzik
2003-04-17 20:01   ` H. Peter Anvin
  -- strict thread matches above, loose matches on Subject: below --
2003-04-17  2:22 Nakajima, Jun
2003-04-17 23:50 Chuck Ebbert

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=20030417190749.GF25696@gtf.org \
    --to=jgarzik@pobox.com \
    --cc=arjanv@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.