On 27/03/2017 01:38, Simon Glass wrote:
Most of the time the optimised memset() is what we want. For extreme
situations such as TPL it may be too large. For example on the 'rock'
board, using a simple loop saves a useful 48 bytes. With gcc 4.9 and
the rodata bug, this patch is enough to reduce the TPL image below the
limit.
Signed-off-by: Simon Glass <s...@chromium.org>
---
lib/Kconfig | 9 +++++++++
lib/string.c | 6 ++++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/lib/Kconfig b/lib/Kconfig
index 65c01573e1..5bf512d8c0 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -52,6 +52,15 @@ config LIB_RAND
help
This library provides pseudo-random number generator functions.
+config FAST_MEMSET
+ bool "Use an optimised memset()"
+ default y
+ help
+ The faster memset() is the arch-specific one (if available) enabled
+ by CONFIG_USE_ARCH_MEMSET. If that is not enabled, we can still get
+ better performance by write a word at a time. Disable this option
+ to reduce code size slightly at the cost of some speed.
The comment sounds slightly confused - it took me a few times of reading
it until I grasped what it was trying to tell me :).
+
source lib/dhry/Kconfig
source lib/rsa/Kconfig
diff --git a/lib/string.c b/lib/string.c
index 67d5f6a421..159493ed17 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -437,8 +437,10 @@ char *strswab(const char *s)
void * memset(void * s,int c,size_t count)
{
unsigned long *sl = (unsigned long *) s;
- unsigned long cl = 0;
char *s8;
+
+#ifdef CONFIG_FAST_MEMSET
+ unsigned long cl = 0;
int i;
/* do it one word at a time (32 bits or 64 bits) while possible */
@@ -452,7 +454,7 @@ void * memset(void * s,int c,size_t count)
count -= sizeof(*sl);
}
}
- /* fill 8 bits at a time */
+#endif /* fill 8 bits at a time */
So while this is all neat, a few ideas:
1) Would having memset in a header improve things even more? After all,
each external function call clobbers registers that you need to
save/restore...
2) How much would GOLD save you? Have you tried? U-Boot is small enough
of a code base that global optimizations should be able to give
significant size savings.
Alex
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
