[Bug libc/23630] x86 multiarch works only for i686 target

[joseph at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23630

--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
When adding subarchitecture variants of functions we need to balance 
speed, size and maintainability, so it's certainly reasonable to say that 
for some variants we will build a working glibc but not try to make it 
particularly optimal, and certainly not try to make it optimal when 
running on a different subarchitecture.  We could reasonably say that 
processors older than those for which -mtune=generic optimizes (which is a 
lot more recent than i686) aren't a target for optimzed code variants, for 
example.

As a matter of maintainability I think it would be a good idea to 
eliminate the i586, i686 and i786 sysdeps directories.  That would mean 
that the i586-optimized functions simply go away.  i686-tuned functions 
that work on i486 would replace the existing generic functions in 
sysdeps/i386; those using i686 instructions would need appropriate 
preprocessor conditionals (which means a version of the compile-time 
condition for HAS_I686 in x86/cpu-features.h would need to be made 
available for .S files, with appropriate conditions to ensure a #error if 
the compiler neither defines any macros known to mean i686, nor defines 
any known to mean pre-i686, to avoid future processors being quietly 
mishandled).  It would be necessary to understand e.g. why the special 
sysdeps/unix/sysv/linux/i386/i686/dl-sysdep.h is present, and whether 
-Wa,-mtune=i686 (used in the i686 makefile) is purely tuning as the name 
suggests or actually requires newer processors.

Note that would mean that glibc built for i486 would *not* have runtime 
choices between i486 and i686 (CMOV etc.) variants; it would have runtime 
choices between i486 and SSE2 etc. variants (whatever variants for 
newer-than-i686 currently exist).

We should also keep under review whether the .S functions are actually 
better than the results of compiling good C code with modern compilers 
(see the various work on improving the generic C versions of string 
functions, which hopefully will get into glibc at some point, for 
example).

> There are two i686 instruction that are not present in i586.

No, there are more.  Some of the i686 function variants use FCOMI / FUCOMI 
instructions (some of those also use FCMOV, some don't).

> Only __ffs() has assembly using "cmov", the rest are compiler generated. I did

I see cmov used in strcmp.S, and in pthread_spin_trylock.S (via HAVE_CMOV 
defined in the i686 directory).

-- 
You are receiving this mail because:
You are on the CC list for the bug.