Hi, On Thu, Sep 16, 2010 at 11:43 AM, Loïc Minier <loic.min...@linaro.org> wrote:
[...] > Are you sure we have an auxv entry for a8 versus a9? In any case, I > doubt it's considered for glibc hwcaps right now as this requires > explicit flagging and the list of ARM flags is quite short. Currently, I believe this information can't be retrieved via auxv. It is available-ish in /proc/cpuinfo. > I don't think this would scale very well to multiple CPUs; it's not > really a CPU feature we're after here, but a CPU characteristic. > GCC has a bunch of costing mechanism at compile time, and I think this > shows that we need some at runtime, probably in all libcs. One way to > workaround in the very short term would be to add some glibc config to > turn on or off usage of NEON, or have glibc read cpuinfo or something > to identify the CPU model and manufacturer. Indeed-- a generally applicable approach would be for libc to provide a few implementations, and for benchmarks to be run to choose which implementation to use. We could have preset defaults for some "common" CPU IDs such as Cortex-A[89] if we want, for when no benchmark result is available. If we go down that road, note that the benchmark can be run quite offline, so it doesn't need to have any startup time impact for applications. But we'd need to put some thought into exactly how this is handled so that we don't end up with stale/wrong configurations. One note of caution here: it's hard to take account of power when running a benchmark on target devices. So if benchmark speed is our only criterion we might make bad choices sometimes. It would be kinda interesting if we could switch the memcpy implementation dynamically as processes execute (depending on the level of CPU load and whether we're trying to save power). This is perhaps a bit fanciful though--- it would be somewhat complex to set up and would require some extra support from libc. I don't know how beneficial it would be. Cheers ---Dave _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
