This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Update list of i686-class processors in sysdeps/x86/cpu-features.h
On Wed, 19 Sep 2018, Florian Weimer wrote:
> * Joseph Myers:
>
> > Question: would it be better to implement this conditional in a
> > negative sense (!defined __i486__ && !defined __i586__ && !defined
> > __geode__, based on what macros are in the fixed conditional, but
> > maybe using __k6__ instead of __geode__ based on GCC's understanding
> > of the options in question) to reduce the chances of it needing
> > updating in future? (__i586__ is actually handled above.)
>
> I think the GCC developers expect that we use the individual feature
> test macros (__SSE2__ etc.). The model-based macros are useless
Which don't exist for CMOV, for example.
We have a general principle that it's best for compile-time selection of
subarchitecture variants of functions to be based on how the compiler
behaves rather than configuring for a variant host triplet or using
--with-cpu. We could e.g. select SSE functions by default based on
__SSE2__ (even if we don't do so at present). But testing whether the
compiler produces a CMOV instruction for particular code seems more
fragile than testing #if conditions for processors without CMOV.
As I suggested in the discussion in bug 23630, I think it would make sense
to eliminate, or at least minimize, the i586 / i686 / i786 sysdeps
directories, to reduce the number of function variants to be maintained;
maybe there are a few places where having conditionals in files on whether
CMOV is supported would be awkward, but in many places either an
i686-tuned version can be used as generic, or only small local
conditionals for CMOV support are needed. E.g.
sysdeps/i386/i686/pthread_spin_trylock.S defines HAVE_CMOV; that ought to
be something available in a generic header, based on some way on what the
compiler predefines.
> > Question: is the inclusion of __k6__ in the present conditional
> > logically incorrect, and the omission of __geode__ logically
> > incorrect, as regards whether to define HAVE_I686? The way GCC
> > defines -march=k6 and -march=geode, it seems to think that the former
> > excludes CMOV and the latter includes it. (-march=geode is
> > specifically "AMD Geode embedded processor with MMX and 3DNow!@:
> > instruction set support.".)
>
> Geode lacks support for long NOPs, but our i686 port requires them.
Requires them where? Through the use of -Wa,-mtune=i686 in
sysdeps/i386/i686/Makefile, or also through explicit uses?
--
Joseph S. Myers
joseph@codesourcery.com