Speed regression caught

[Torbjörn Granlund]

I have long worried that our meticulously tuned library suffers from
speed regressions which are unnoticed.  I am aware of many ways this may
happen!

I just now discovered that 64-bit Atom (the original ones, not
Silvermont and later) had a major regression for mpn_add_n and
mpn_sub_n, from 3 c/l to about 4.3 c/l.  These old Atoms are the most
important CPUs for GMP, so no real harm done.

The x86_64/atom/aors_n.asm file originally had fast code, then later was
changed to just include x86_64/coreisbr/aors_n.asm which also happened
to run optimally for Atom.  That was fine when that was arranged, but
then the latter file was rewritten, and the new code was not good for
Atom.  Regression!

We need a broad mechanism for catching regressions, both sudden ones and
gradual ones over time.

(I implemented good Atom code now by staring with Marco's
x86/atom/aors_n.asm and trivially edit it to make it 64-bit.  I could
have reverted to the old Atom-specific code, but Marco's code is neater
and had a few cycles less overhead.)

-- 
Torbjörn
Please encrypt, key id 0xC8601622