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

["ikalvachev at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #6 from Ivan Kalvachev <ikalvachev at gmail dot com> ---
(In reply to joseph@codesourcery.com from comment #5)
> i386 and x86 sysdeps directories mean different things: i386 is 
> specifically 32-bit (now i486 or later), x86 is for code shared between 
> 32-bit and 64-bit (code common to i386 and x86_64, including x32).
> 
> Note that 32-bit SPARC only has multiarch for sparcv9, 32-bit Power only 
> has it for POWER4 and later and 32-bit Arm only has it for Armv7 and 
> later.  That is, it's normal for the multiarch support to be only for 
> modern processors, with an expectation that if someone is building for an 
> older architecture variant they are building for one particular system 
> with a particular old processor, not for a general-purpose distribution 
> that may run on a wide range of hardware.

You know, one bad thing does not excuse another bad thing.
It's even worse if your argument is that you are systematically bad.

I do not like your entirely arbitrary definition of "modern processor", either.
Is Pentium Pro a modern processor? And if it is, then by what definition its
predecessor Pentium is not?

I do prefer to argue about concrete technical limitations.

What we are talking here is literally picking hand written assembly
speed-critical functions, selected by the result of CPUID test.

I'm not familiar with these other architectures you mention, but I do suspect
that in most cases, there is no reliable way to figure out the exact
architecture of the running processor, and/or instruction sets are not 100%
backward compatible (without missing significant speed boost).

Neither of these things are valid for x86_32.

---

There are two i686 instruction that are not present in i586.
"UD2" is guaranteed to cause invalid instruction (for trap testing).
"CMOV" is a branch-less conditional move. With modern jump prediction and
speculative out-of-order execution its speed benefits are not that significant,
and in few extreme cases could even be slower.
Only __ffs() has assembly using "cmov", the rest are compiler generated. I did
count the conditional moves over the conditional branches in i686 libc.so .
They are 783/47209 or around 1,7%.

---

There are three userland i586 instructions not present in i486.
"CMPXCHG8B" 64bit atomic compare and exchange. Not used by any library in my
i686 glibc-2.28 build.
"RDTSC" reads timestamp counter. Could be used by gettimeofday() as high
precision clock source. Some AMD CPUs have a nasty quirk with it...
"CPUID" reports details about supported instruction sets, architecture etc.. 
To avoid triggering illegal instruction, CPUID support is detected by setting
the 21bit in the EFLAG Register.

---

I'll state it this way. There are no technical reasons to not support
multi-arch on i586 (or i486).

Currently i586 glibc-2.28 fails during build if configured with --multi-arch.
There is no documentation stating i686 is the only supported multi-arch.

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