* [RFC/PATCH] powerpc: Always use -mno-string & -mno-multiple
@ 2007-03-22 6:10 Benjamin Herrenschmidt
2007-03-22 12:02 ` Segher Boessenkool
0 siblings, 1 reply; 3+ messages in thread
From: Benjamin Herrenschmidt @ 2007-03-22 6:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Akinobu Mita
powerpc: Always use -mno-string and -mno-multiple
The string and multiple load/store instructions are causing more
damage than help on a lot of processors where they are microcoded
and are generally no good for the kernel to use. Let's make sure
we don't emit them on any powerpc variant.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Is that actually true ? What about 601 ? 4xx ? Do we want to keep
generating those for space on embedded processors where they actually
work (if they do) ?
Index: linux-cell/arch/powerpc/Makefile
===================================================================
--- linux-cell.orig/arch/powerpc/Makefile 2007-03-22 17:02:42.000000000 +1100
+++ linux-cell/arch/powerpc/Makefile 2007-03-22 17:05:23.000000000 +1100
@@ -102,9 +102,9 @@ CFLAGS += $(call cc-option,-mno-altivec)
# kernel considerably.
CFLAGS += $(call cc-option,-funit-at-a-time)
-ifndef CONFIG_FSL_BOOKE
-CFLAGS += -mstring
-endif
+# Never use string and multiple load/store instructions as they are
+# often slow when they are implemented at all
+CFLAGS += -mno-string -mno-multiple
ifeq ($(CONFIG_6xx),y)
CFLAGS += -mcpu=powerpc
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC/PATCH] powerpc: Always use -mno-string & -mno-multiple
2007-03-22 6:10 [RFC/PATCH] powerpc: Always use -mno-string & -mno-multiple Benjamin Herrenschmidt
@ 2007-03-22 12:02 ` Segher Boessenkool
2007-03-22 12:06 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 3+ messages in thread
From: Segher Boessenkool @ 2007-03-22 12:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Akinobu Mita, Paul Mackerras, linuxppc-dev list
> powerpc: Always use -mno-string and -mno-multiple
>
> The string and multiple load/store instructions are causing more
> damage than help on a lot of processors where they are microcoded
> and are generally no good for the kernel to use. Let's make sure
> we don't emit them on any powerpc variant.
And they help a lot on many 32-bit CPUs. NAK.
If you tell your GCC to compile for a certain CPU where
these insns would be very slow, GCC will automagically
not generate them, already.
Segher
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC/PATCH] powerpc: Always use -mno-string & -mno-multiple
2007-03-22 12:02 ` Segher Boessenkool
@ 2007-03-22 12:06 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 3+ messages in thread
From: Benjamin Herrenschmidt @ 2007-03-22 12:06 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Akinobu Mita, Paul Mackerras, linuxppc-dev list
On Thu, 2007-03-22 at 13:02 +0100, Segher Boessenkool wrote:
> > powerpc: Always use -mno-string and -mno-multiple
> >
> > The string and multiple load/store instructions are causing more
> > damage than help on a lot of processors where they are microcoded
> > and are generally no good for the kernel to use. Let's make sure
> > we don't emit them on any powerpc variant.
>
> And they help a lot on many 32-bit CPUs. NAK.
>
> If you tell your GCC to compile for a certain CPU where
> these insns would be very slow, GCC will automagically
> not generate them, already.
multiple do, strings really don't much except maybe on 601.... we don't
quite yet have the options to compile for specific CPUs on arch/powerpc
so -mno-string is a good idea generally, though I agree -mno-multiple
isn't, thus my next patch :-)
Ben.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-03-22 12:06 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-03-22 6:10 [RFC/PATCH] powerpc: Always use -mno-string & -mno-multiple Benjamin Herrenschmidt
2007-03-22 12:02 ` Segher Boessenkool
2007-03-22 12:06 ` Benjamin Herrenschmidt
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 NNTP newsgroup(s).