tune&fat: run-time vs. compile-time constant thresholds

[Torbjorn Granlund]

bodrato at mail.dm.unipi.it writes:

  Many macros in our code assume that thresholds are compile-time constants,
  e.g. the MAYBE_ machinery in toom code, but also the ABOVE_THRESHOLD
  macro, with its three stage comparison...
  
  #define ABOVE_THRESHOLD(size,thresh)					\
    ((thresh) == 0							\
     || ((thresh) != MP_SIZE_T_MAX					\
         && (size) >= (thresh)))
  
  Most of this code is disabled #if TUNE_PROGRAM_BUILD, but compiled for
  fat-builds...
  
With consequences not completely understood...

  I suggest to define a unique THRESHOLDS_ARE_NOT_HARDCODED macro, to be
  used by both tune and fat builds, and start using it instead of the
  TUNE_PROGRAM_BUILD condition.
  
  Is this possible? Do you think it makes sense?
  
I am not sure exactly what behaviour change you are trying to achieve,
but I assume it is good.  :-)

Improving the state of fat builds is important.  There are several
things to improve, perhaps your effort addresses some of these?

1. Compile (more) small operands code specifically (i.e., add them to
   fat_functions).  Perhaps a few toom functions should be added?

2. Provide more thresholds (i.e., add them top fat_thresholds).

3. Make thresholds effective (in toom, etc)

4. In a shared lib fat build, don't do too many indirections (via our
   tables addressed via GOT, with entries pointing to PLT entries...).

5. Add some fall-back CPU detection code (to fat.c), handling new
   processors better.

-- 
Torbjörn