longlong.h and cpu type vectoring...
tg at gmplib.org
Mon Apr 8 17:17:47 CEST 2013
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
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
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.
More information about the gmp-devel