Skip to content
  • Timothy B. Terriberry's avatar
    Add runtime CPU detection support for ARM. · b71962fd
    Timothy B. Terriberry authored
    The primary goal is to allow a binary to be built which supports
     NEON, but can fall back to non-NEON routines, since some Android
     devices do not have NEON, even if they are otherwise ARMv7 (e.g.,
    The configure-generated flags HAVE_ARMV7, etc., are used to decide
     which versions of each function to build, and when
     CONFIG_RUNTIME_CPU_DETECT is enabled, the correct version is chosen
     at run time.
    In order for this to work, the CFLAGS must be set to something
     appropriate (e.g., without -mfpu=neon for ARMv7, and with
     appropriate -march and -mcpu for even earlier configurations), or
     the native C code will not be able to run.
    The ASFLAGS must remain set for the most advanced instruction set
     required at build time, since the ARM assembler will refuse to emit
     them otherwise.
    I have not attempted to make any changes to configure to do this
    Doing so will probably require the addition of new configure options.
    Many of the hooks for RTCD on ARM were already there, but a lot of
     the code had bit-rotted, and a good deal of the ARM-specific code
     is not integrated into the RTCD structs at all.
    I did not try to resolve the latter, merely to add the minimal amount
     of protection around them to allow RTCD to work.
    Those functions that were called based on an ifdef at the calling
     site were expanded to check the RTCD flags at that site, but they
     should be added to an RTCD struct somewhere in the future.
    The functions invoked with global function pointers still are, but
     these should be moved into an RTCD struct for thread safety (I
     believe every platform currently supported has atomic pointer
     stores, but this is not guaranteed).
    The encoder's boolhuff functions did not even have _c and armv7
     suffixes, and the correct version was resolved at link time.
    The token packing functions did have appropriate suffixes, but the
     version was selected with a define, with no associated RTCD struct.
    However, for both of these, the only armv7 instruction they actually
     used was rbit, and this was completely superfluous, so I reworked
     them to avoid it.
    The only non-ARMv4 instruction remaining in them is clz, which is
     ARMv5 (not even ARMv5TE is required).
    Considering that there are no ARM-specific configs which are not at
     least ARMv5TE, I did not try to detect these at runtime, and simply
     enable them for ARMv5 and above.
    Finally, the NEON register saving code was completely non-reentrant,
     since it saved the registers to a global, static variable.
    I moved the storage for this onto the stack.
    A single binary built with this code was tested on an ARM11 (ARMv6)
     and a Cortex A8 (ARMv7 w/NEON), for both the encoder and decoder,
     and produced identical output, while using the correct accelerated
     functions on each.
    I did not test on any earlier processors.
    Change-Id: I45cbd63a614f4554c3b325c45d46c0806f009eaa