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. -Austin _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
