Re: [PATCH] Add cmov into i386 HWCAP_IMPORTANT

[GOTO Masanori <gotom at debian dot or dot jp>]

At Sun, 2 Feb 2003 00:29:13 +0100,
Jakub Jelinek wrote:
> 
> On Sat, Feb 01, 2003 at 10:37:20PM +0100, Jakub Jelinek wrote:
> > On Sun, Feb 02, 2003 at 06:29:45AM +0900, GOTO Masanori wrote:
> > > Hi,
> > > 
> > > This patch adds HWCAP_I386_CMOV into i386 HWCAP_IMPORTANT.
> > > 
> > > CMOV is i686 optional instruction, and VIA C3 processor does not
> > > support it, but VIA C3 reports it's an i686 class processor.  
> > > 
> > > Unfortunately, gcc generates this optional CMOV instruction with
> > > -mcpu=i686 optimization, so i686 optimized dynamic library code almost
> > > causes "illegal instruction" error on VIA C3 processor during dynamic
> > > loading.  I heard that gcc team does not think to change using CMOV
> > > instruction with i686 optimization.  CMOV is very key instruction to
> > > make faster.
> > > 
> > > But I think this patch is needed regardless of gcc generates cmov
> > > instruction code with i686 optimization.  Please apply it.
> > 
> > Guess you're aware about how much this penalizes everybody using
> > DT_R{,UN}PATH and LD_LIBRARY_PATH...

Yes, it's my concern, this change causes a lot of file search...

But this search mechanism does not appropriate if we have more than
two HWCAP bits (for example: arm and sparc)...  Well, it's hard to
define its search order (it may be changed "In first, 1st dir level
lookup, then 2nd dir level lookup, ..." strategy).

However, how do you think about HWCAP_I386_MMX?  MMX is also used as
HWCAP_IMPORTANT...  Is it _really_ needed?

At least if some libraries put in i686 directory with cmov code, we
can't handle them on VIA C3 correctly.  In such case, we have no way
to stop causing "illegal instruction".  It's just time where HWCAP
come in...  If I have no understanding, please admonish me.

> > IMHO way better is just change platform to i586 when cmov hwcap is not set.
>
> Note that that should be done in the kernel, not in ld.so.

VIA C3 supports i686 class processor facilities, but it lacks cmov
_optional_ instruction.

Dave Jones and Alan Cox said that it has i686 function, but not cmov,
so they think it's i686 class processor.  I don't know it's correct or
not (and my opinion is they should report i486 class processor).
However, if gcc does not generate CMOV instruction, then it's ok to
report it's an i686 class processor.  So should we report it as
"i586"?  No.

I heard GCC team does not change using cmov instruction with
-march=i686, because "CMOV" instruction seems important (I don't know
its precious gain, because I've never gotten benchmark data, but it
seems that generating cmov instruction with -march=i686 brings us much
improvement).  The number of VIA C3 processor in "i686 class"
processor is only "<1%".  I also use Athlon and Pentium, I don't want
to downgrade its speed. :)

VIA C3 user should use gcc-3.3 -mcpu=c3 option to optimize their code.
Hand asm-optimized binaries/libraries like audio/video applications
should detect it's cmov aware or not.


Now glibc.  Glibc has no relation this issue except for dynamic
libraries.  Repeatly, if some libraries put in i686 directory with
cmode code, then we load them, and an application gets error.  "i386
hwcap" is surely existed for this purpose, I think.


VIA C3 is not complete i686 class processor, it pretends their
facilities in order to sell.  I know this issue stands for a long
time, and what I only know is there are VIA C3 processor users and
they have trouble in using i686 optimized code.  In Debian few users
use C3, so to be honest I don't want to think about VIA C3 :-) However
we have such users so we should fix this problem even if VIA C3 is not
complete processor.  I've never want to put the blame on someone...
Weigh which parts should change.  (I heard rpm has some mechanism to
detect it with -i686 package. it's ugly but good way, I think).

Thanks in advance,
-- gotom