Semi-automated asm selection

[Torbjörn Granlund]

New CPUs come out from AMD and Intel, sometimes using existing core with
different cpuid values, sometimes with new cores with different
characteristics.

Only years later are we GMP hackers able to choose good asm code for
these CPUs and make a release.  Furthermore, out process for that is
irksome, often incomplete, and somewhat prone to (harmless) mistakes.

Perhaps we could automate it?  Perhaps our dear users could use that
same automation for the brand spanking new CPUs for which we have not
yet provided tuned asm selection?

How would that be done?

Today we have lots of asm files in (say) mpn/x86_64.  For the
performance-critical mpn_addmul_1, we have these:

silvermont/aorsmul_1.asm   <<
mulx/adx/addmul_1.asm
goldmont/aorsmul_1.asm     <<
zen3/addmul_1.asm          <<
zen/aorsmul_1.asm
bt1/aorsmul_1.asm
alderlake/addmul_1.asm
coreisbr/aorsmul_1.asm
bd1/aorsmul_1.asm
core2/aorsmul_1.asm
coreinhm/aorsmul_1.asm
atom/aorsmul_1.asm
coreibwl/addmul_1.asm
aorsmul_1.asm
pentium4/aorsmul_1.asm     <<
coreihwl/aorsmul_1.asm

The main choice of files are made with an asm search path set from the
CPU model (as recognised by our special config.guess) in configure.ac.
But it granularity isn't great, so we override it with simple "inclusion
files" which just include the contents of some other file.  These files
are marked with "<<" above.


Considered improvement:

In order to make some sort of automated choice of asm code, we need to
generate and use a list of the best found asm code for each function.
Such a list would be stored in CPU specific files and could look
something like this:

addmul_1=coreibwl/addmul_1.asm
submul_1=zen/aorsmul_1.asm
...

Such files would supplant the "inclusion files", and configure.ac would
be made to read them.

How would they be generated?  Presumably, tune/speed.c could be made to
help.  But I have started on a separate program, which does a few things
differently:

1. For each measured function, it computes a geometric average of the
cycle counts for a relevant range of operand sizes.

2. It makes two consecutive invocations dependent, to thwart
out-of-order execution.  (Out-of-order has become so deep that two
consecutive invocations overlap significantly, thus hiding unwanted
latencies within measured loops.)

3. It always uses a proper cycle counter (such as rdtsc) to avoid
getting fooled by "turbo".  (Perhaps this is not important, as long as
all measurements are made in the same way.)


Finally, we need to allow a user to generate such files, and let them
tell a consecutive build to use a newly generated file (without editing
the GMP *config* files!).


Comments?

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