Test for native (fast) 64-bit integer type?

[l***@cs.columbia.edu]

Hi --

Does anyone have any idea as to how one could write an Autoconf test to
check whether long long (or int64_t, or whatever) is implemented natively,
and so is likely to be fast, as opposed to being emulated by the compiler as
a pair of 32-bit values?

(SIZEOF_LONG == 8 || SIZEOF_VOID_P == 8) would seem to reflect it with high
probability, but a) wouldn't detect x32, MIPS n32, and the like (i.e., ILP32
ABIs on 64-bit CPUs), and b) is out of the "spirit" of Autoconf tests, since
it's not actually detecting the thing we're looking for.

I could check whether compiling [long long foo(long long x, long long y) {
return x/y;}] uses any external functions, or call AC_CHECK_FUNC([__lldiv]),
but this also seems fragile (and in the latter case GCC-specific, unless I
want to catalog every compiler runtime's long long division routine).

Does anyone have any thoughts about the best way to detect this feature
directly?

(The motivation is tight-loop math operations that on 32-bit architectures
can be implemented more efficiently than using most compilers' generic
emulated 64-bit math routines, but on 64-bit architectures should just use
native 64-bit operations.)

[Nick Bowler]

Post by l***@cs.columbia.edu
Does anyone have any idea as to how one could write an Autoconf test to
check whether long long (or int64_t, or whatever) is implemented natively,
and so is likely to be fast, as opposed to being emulated by the compiler as
a pair of 32-bit values?

[...]

Post by l***@cs.columbia.edu
(The motivation is tight-loop math operations that on 32-bit architectures
can be implemented more efficiently than using most compilers' generic
emulated 64-bit math routines, but on 64-bit architectures should just use
native 64-bit operations.)

Even if a CPU has instructions which perform 64-bit integer operations,
there is no guarantee that they are fast.

Have you looked at existing free math packages to see if they have any
relevant tests?

It sounds like in your case the penalty for choosing wrong is simply
reduced performance. So if I were implementing this, I would start by
adding a user switch like --enable-64bit-ops (AC_ARG_ENABLE[1]) to allow
the user to force the selection one way or the other. You may decide
that this is sufficient.

For a better "out of the box" experience you can implement an automatic
default selection based on heuristics (such as the tests described in
your original mail, but I also suggest looking at AC_CANONICAL_CPU[2]
and $host_cpu). Since the user can always override it, it's not the end
of the world if your heuristics choose the slower option, and they can
be improved as necessary.

[1] https://gnu.org/software/autoconf/manual/autoconf.html#AC_005fARG_005fENABLE
[2] https://gnu.org/software/autoconf/manual/autoconf.html#index-AC_005fCANONICAL_005fHOST-1925

Cheers,