diff options
author | Nicolas Pitre <nicolas.pitre@linaro.org> | 2018-01-19 18:17:46 +0100 |
---|---|---|
committer | Russell King <rmk+kernel@armlinux.org.uk> | 2018-01-21 15:37:56 +0000 |
commit | ff5fdafc9e9702846480e0cea55ba861f72140a2 (patch) | |
tree | 28531d5acbc851bf5f210062bc9d0e08f1fee85e /sound/soc/soc-dapm.c | |
parent | ec80eb467171b511635b9e3086fec357f79afe3b (diff) | |
download | op-kernel-dev-ff5fdafc9e9702846480e0cea55ba861f72140a2.zip op-kernel-dev-ff5fdafc9e9702846480e0cea55ba861f72140a2.tar.gz |
ARM: 8745/1: get rid of __memzero()
The __memzero assembly code is almost identical to memset's except for
two orr instructions. The runtime performance of __memset(p, n) and
memset(p, 0, n) is accordingly almost identical.
However, the memset() macro used to guard against a zero length and to
call __memzero at compile time when the fill value is a constant zero
interferes with compiler optimizations.
Arnd found tha the test against a zero length brings up some new
warnings with gcc v8:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82103
And successively rremoving the test against a zero length and the call
to __memzero optimization produces the following kernel sizes for
defconfig with gcc 6:
text data bss dec hex filename
12248142 6278960 413588 18940690 1210312 vmlinux.orig
12244474 6278960 413588 18937022 120f4be vmlinux.no_zero_test
12239160 6278960 413588 18931708 120dffc vmlinux.no_memzero
So it is probably not worth keeping __memzero around given that the
compiler can do a better job at inlining trivial memset(p,0,n) on its
own. And the memset code already handles a zero length just fine.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Diffstat (limited to 'sound/soc/soc-dapm.c')
0 files changed, 0 insertions, 0 deletions