Shared toom evaluation functions

Torbjorn Granlund tg at
Thu Nov 19 15:02:14 CET 2009

I think we might want to make our lives in toom more difficult:

We should add, to gmp-mparam.h, cycle counts for available mpn functions
as first degree polynomials.  Measurements for that can easily be added
to tuneup.c.

Then, instead of using the HAVE_NATIVE mechanisms, we should do things


In gmp-mparam.h:

#define POLY_ADD_N	250,1500	// 250/100 = 2.5 cycles per limb
					// plus 1500/100 = 15 cycles of overhead

We could avoid the HAVE_NATIVE stuff if we define the absence of a
function cleverly:

#ifndef POLY_ADD_N

This would allow complete folding of the expression, since the
evaluation of that polynomial would always give MP_SIZE_T_MAX and no
value is ever greater than MP_SIZE_T_MAX.

For toom, what n should we pass to EVAL_POLY1?  I think it is best to
pass the low threshold.  Or perhaps just an estimated magic value which
we expect to be representative.  It sounds silly, but there are
advantages of dong the latter: It will make the expression always
foldable at compile time, which allow us to use #if.  And I am pretty
sure it would work very well in practice.  (Using *_THRESHOLD parameter
will cause trouble in tuneup.c, where these are made into variables.)


More information about the gmp-devel mailing list