Remove sub-arch/variants selection from the menuconfig
austinf at cetoncorp.com
Tue Jan 26 22:32:58 UTC 2010
On 01/26/2010 02:19 PM, Yann E. MORIN wrote:
> Bernhard, All,
> On Tuesday 26 January 2010 19:48:10 Bernhard Reutner-Fischer wrote:
>>> On Monday 25 January 2010 21:49:25 Yann E. MORIN wrote:
>>>> It is not the responsibility of the C library to select what sub-arch
>>>> to generate code for. Rely on the user to:
>>>> - either use a compiler that is configured to generate optimised code
>>>> for the target actual target,
>>>> - or set UCLIBC_EXTRA_CFLAGS with the correct incantation of -march,
>>>> -mcpu, and the likes.
>> With this approach we will just break e.g. sparc who do not (AFAICS)
>> have means to distinguish their ISAs?
> My gcc (Debian 4.3.4-6~bpo50+1) has -mcpu= and -mtune= flags (and can
> be configured with --with-cpu= and --with-tune= flags) to specify the
> processor generation, and thus the acceptable instruction set. The
> possible values are (from man gcc):
> Sparc arch Implementation
> v7 cypress
> v8 supersparc, hypersparc
> sparclite f930, f934, sparclite86x
> sparclet tsc701
> v9 ultrasparc, ultrasparc3, niagara, niagara2
> The -mcpu=[Sparc arch] flag only sets the instruction set, while the
> -mcpu=[Implementation] flag sets the instruction set, and optimises for
> the scpecific implementation. The -mtune=[whatever] flag only sets the
> scheduling optimisations.
I think what he means is that gcc doesn't provide explicit
builtin_define's to let anyone but it know what version of the
architecture is currently selected. So this breaks us selecting the
correct optimized version of string and math functions.
However after discussing on IRC, I think we can figure out what is
selected implicitly via the builtin_define's it does provide to an
acceptable level so that we won't break anything.
More information about the uClibc