From: Segher Boessenkool <segher@kernel.crashing.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Akinobu Mita <mita@fixstars.com>,
cbe-oss-dev@ozlabs.org,
linuxppc-dev list <linuxppc-dev@ozlabs.org>
Subject: Re: [Cbe-oss-dev] [PATCH] force -mno-string option on cell
Date: Mon, 26 Mar 2007 14:00:31 +0200 [thread overview]
Message-ID: <7f2c3c749a9c5b836354e4f0c6343e6d@kernel.crashing.org> (raw)
In-Reply-To: <200703232146.21224.arnd@arndb.de>
>> It would be even better to not lie to the compiler by
>> telling it it can use the LS area as normal memory, since
>> evidently it cannot :-)
>
> Yes, this is the important point. I actually think the first
> patch that just replaces memcpy with memcpy_fromio is the
> right solution for the specific problem.
Not only is it the _right_ solution, it actually _is_ a
solution -- adding -mno-string only sweeps one particular
symptom under the rug, it doesn't fix anything.
> Avoiding certain instructions in the kernel may be a good
> thing to do as well,
Only if there is something special about the kernel wrt
those instructions. For example, if certain insns cannot
execute in supervisor mode on some CPU.
If there is no such special consideration, you should
just let GCC do its job (and if you think it makes bad
insn selection choices, you know where to come complain).
> but this is not at all a cell specific
> thing.
Indeed.
> Maybe we should have a more detailed CPU selection Kconfig
> option like
>
> CPU Family
> * 64 bit common (power3/4/5/6, ppc970, cell, *star)
> * 32 bit common (6xx, 82xx, 83xx, 86xx)
> * 40x/44x
> * ...
Useful. This could at least partly be derived / defaulted
from the platform support that is already selected, too.
> Minimum supported CPU (gcc -march=, depending on above selection)
> * 603
> * 604
> * 750
> * power3
> * power4
> * 970
There is no -march= option. You mean -mcpu= I think?
> Optimize for CPU (gcc -mtune)
> (subset of the -march list as before)
-mcpu= implies -mtune= for the same CPU. I don't think
many people would ever want to set something else.
Btw, when you install GCC, you can select its default
-mcpu= target: ../gcc/configure --with-cpu=970 . It
helps ;-)
Segher
next prev parent reply other threads:[~2007-03-26 12:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-22 6:23 [PATCH] powerpc: Always use -mno-string Benjamin Herrenschmidt
2007-03-22 12:06 ` Segher Boessenkool
2007-03-23 12:06 ` [PATCH] force -mno-string option on cell Akinobu Mita
2007-03-23 12:56 ` Segher Boessenkool
2007-03-23 19:38 ` Benjamin Herrenschmidt
2007-03-24 0:02 ` Segher Boessenkool
2007-03-23 20:46 ` [Cbe-oss-dev] " Arnd Bergmann
2007-03-26 12:00 ` Segher Boessenkool [this message]
2007-03-24 3:02 ` Paul Mackerras
2007-03-24 14:46 ` Segher Boessenkool
2007-03-23 13:37 ` Kumar Gala
2007-03-23 16:35 ` Segher Boessenkool
2007-03-23 19:46 ` Benjamin Herrenschmidt
2007-03-24 0:04 ` Segher Boessenkool
2007-03-26 8:54 ` Geert Uytterhoeven
2007-03-26 12:33 ` Segher Boessenkool
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=7f2c3c749a9c5b836354e4f0c6343e6d@kernel.crashing.org \
--to=segher@kernel.crashing.org \
--cc=arnd@arndb.de \
--cc=cbe-oss-dev@ozlabs.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mita@fixstars.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 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).