longlong.h and cpu type vectoring...

[Torbjorn Granlund]

David Miller <davem at davemloft.net> writes:

  Through a twisty passage I came across this issue which we'll
  need to address in some way in the near future.
  
  I noticed that the longlong.h included in gmp lacks a lot of
  sparc optimizations, and in particular umul_ppmm doesn't use
  mulx/umulxhi when it could.
  
I added such code, but since I couldn't find any cpp symbol which is
triggered by -mvis2, I invented a name we need to set ourselves.

Incidentally, we don't set any -mvis options in configure.ac.

  But this got me thinking of a much larger issue.  When we have
  cpu function vectors or ifunc relocations, we really have to
  be careful how we enable such instructions in a header file
  like longlong.h

Indeed.

We need to disable conditionally available instructions both by passing
the right compiler options and by controlling features like longlong.h.

Currently we support fat builds for just x86-32 and x86-64.  We seem to
get these things right there.  I'd like to add fat support for more
architectures, like ARM, PPC, SPARC.

  Currently the HAVE_* macros get defined based upon the target
  configured, and this ends up enabling different optimizations in
  longlong.h
  
  But these end up being used in generic pieces of code, basically
  anything that uses the longlong.h interfaces will be susceptible
  to this issue.
  
  Anyways, just thought I'd bring this to everyone's attention.

I am somewhat aware of this.  This is both a correctness issue (i.e.,
not using unavailable instructions) and efficiency issue (use available
instructions for critical code).

We can counter the efficiency reason by concentrating critical code to
few loops in C or assembly, which we then put into __gmpn_cpuvec.  Then,
we could put more slightly higher-level routines in __gmpn_cpuvec, which
can then without overhead call other truly low-level functions.

-- 
Torbjörn