Fat binaries should always honor GMP_CPU_TYPE

[librik@panix.com]

I've been testing the "fat binary" feature of GMP 4.2, and I'm
really impressed.  Performance is better on every machine I've
tried, compared to the generic assembler version of 4.1.4.

One nice element of the x86 fat binary code is the WANT_FAKE_CPUID
define, which replaces actual CPU identification with the
GMP_CPU_TYPE environment variable.  This makes it possible to
build a modified GMP suitable for testing:  If you don't have all
the older platforms on hand, you can at least exercise their code
paths by setting the environment variable.

But I want to argue that it is the Right Thing to have something
like WANT_FAKE_CPUID active all the time.  It should be possible
to build GMP 4.2 so that the environment variable GMP_CPU_TYPE,
if it is set, overrides fat-binary CPU detection.

Why this would be a win:

* A GMP user with a new or unrecognized generation of x86 CPU
  could set GMP_CPU_TYPE to the nearest match, rather than have
  to drop down to the basic i486 code.

* If a bug or problem is found in a certain processor's MPN
  assembly code, setting GMP_CPU_TYPE makes it possible to
  avoid that module and fall back on a known-good replacement.

  This can even be done programmatically inside a client of GMP,
  since CPUID isn't called until the first GMP operation.

* Testing a GMP-based application on all x86 code paths is easier
  without having to find old systems or use a specially-patched
  GMP binary.

* Environment variables as back-doors to control libraries are
  well-established in *nix -- cf. OMP_NUM_THREADS in OpenMP.

I can't see any good reason not to allow this, really, at least
as a configuration option.  The mpn/x86/fat/fat.c file is written
in a modular way, so this is a pretty easy code change.

(Free and open-source software benefits, since users of applications
based on GMP do not necessarily have the experience or resources to
rebuild a bundled library.  It gives the application developer an
incredibly useful tool to solve problems that might arise after her
program goes out the door.)

Can anyone tell me why this would be a bad move?  I'd like to
strongly suggest it for GMP 4.2.1.

Sincerely,

- David Librik
librik at panix.com