| #
f23d26d7 |
| 16-Apr-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
fix(libc): add the memcpy declaration back
Patch 34d7f196b moved definitions to a new file but missed that of memcpy. Put it back.
Change-Id: I5e9797e611e6f1f97232f03de98f81db86a66c2a Signed-off-by
fix(libc): add the memcpy declaration back
Patch 34d7f196b moved definitions to a new file but missed that of memcpy. Put it back.
Change-Id: I5e9797e611e6f1f97232f03de98f81db86a66c2a Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| #
34d7f196 |
| 17-Mar-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
perf(libc): use builtin implementations where possible
When conditions are right, eg a small memcpy of a known size and alignment, the compiler may know of a sequence that is optimal for the given c
perf(libc): use builtin implementations where possible
When conditions are right, eg a small memcpy of a known size and alignment, the compiler may know of a sequence that is optimal for the given constraints and inline it. If the compiler doesn't find one, it will emit a call to the generic function (in the libc) which will implement this in the most generic and unconstrained manner. That generic function is rarely the most optimal when constraints are known.
So give the compiler a chance to do this. Replace calls to libc functions that have builtins to the builtin and keep the generic implementation if it decides to emit a call anyway.
And example of this in action is usage of FEAT_MOPS. When the compiler is aware of the feature (-march=armv8.8-a) then it will emit the 3 MOPS instructions instead of calls to our memcpy() and memset() implementations.
Change-Id: I9860cfada1d941b613ebd4da068e9992c387952e Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|