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
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 19 Sep 2018 08:33:16 +0200
- Subject: Re: Update list of i686-class processors in sysdeps/x86/cpu-features.h
- References: <alpine.DEB.2.21.1809172305170.13111@digraph.polyomino.org.uk>
* 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
because CPU features are increasingly non-monotonic, and it does not
make sense to replicate GCC's view of the Intel and AMD roadmaps in
glibc.
> 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.