a13d0660fe
clang was getting in the way of a strftime(3) optimization, and smaller hammers weren't working, and this seems like the right choice for libc anyway? If we have code that can usefully be optimized, we should do it in the source. In general, though, no libc/libm author should be ignorant of memset(3) or memcpy(3), and would have used it themselves if it made sense. (And the compiler isn't using profiling data or anything; it's just always assuming it should use the functions, and doesn't consider whether the cost of the calls can be amortized or not.) Test: treehugger Change-Id: Ia7e22623e47bfbfcfe46c1af0d95ef7e8669c0f6 |
||
---|---|---|
.. | ||
amd64 | ||
arm | ||
arm64 | ||
i387 | ||
upstream-freebsd | ||
upstream-netbsd | ||
x86 | ||
x86_64 | ||
Android.bp | ||
builtins.cpp | ||
digittoint.c | ||
fake_long_double.c | ||
fenv-access.h | ||
fpmath.h | ||
freebsd-compat.h | ||
libm.map.txt | ||
MODULE_LICENSE_BSD_LIKE | ||
NOTICE | ||
signbit.cpp | ||
significandl.c |