Simon Josefsson wrote:
> If we are splitting this module up into several, maybe it even make more
> sense to have a 'crc-slice-by-8' module for that particular portable
> optimization. I have one use-case (although not published so less
> important) where the table size increase is a problem, and would prefer
> to use the current smaller crc.c (or even better, a smaller one that
> generate the tables on the fly, I forgot that it is possible).
We use different modules for different functionality. (So, for example,
CRC with a different polynomial could be a different module. Or it
could be in the same module if most of the tables and code are the same.)
For optimizations, we have other techniques available:
- For optimizations that the package developer can enable:
That package can invoke a particular Autoconf macro in its configure.ac.
The effect of this macro is typically to initialize a configure-time
variable.
- For optimizations that the installer / distributor can enable:
An --enable/--disable option, through AC_ARG_ENABLE.
- For optimizations that the user can enable:
An environment variable.
- For optimizations that are enabled by default, depending on CPU
features: A feature check at runtime, whose result is cached in a
static variable. (/proc/cpuinfo, getauxval(AT_HWCAP), cpuid instruction,
__x86_get_cpuid_feature_leaf, `ld.so --list-diagnostics`)
Bruno
