Hi Andrew,
On 12/05/17 16:30, Andrew Cooper wrote:
On 12/05/17 15:56, Jan Beulich wrote:
On 12.05.17 at 16:34, <andrew.coop...@citrix.com> wrote:
--- a/xen/include/asm-x86/string.h
+++ b/xen/include/asm-x86/string.h
@@ -10,4 +10,12 @@
#define __HAVE_ARCH_MEMSET
#define memset(s, c, n) __builtin_memset(s, c, n)
+#define strcmp(s1, s2) __builtin_strcmp(s1, s2)
+#define strncmp(s1, s2, n) __builtin_strncmp(s1, s2, n)
+#define strcasecmp(s1, s2) __builtin_strcasecmp(s1, s2)
+#define strchr(s1, c) __builtin_strchr(s1, c)
+#define strrchr(s1, c) __builtin_strrchr(s1, c)
+#define strstr(s1, s2) __builtin_strstr(s1, s2)
+#define strlen(s1) __builtin_strlen(s1)
If the lack of __HAVE_ARCH_* additions is intentional here,
Yes - it is deliberate.
why do you keep them for mem*()?
We have x86-specific implementation of mem*(), while we use the common
implementation of str*().
Defining __HAVE_ARCH_STR* causes the common implementation to be
omitted, resulting in a link failure.
Given that all supported compilers have these builtins, I think it might
be better to make this adjustment in common code. The arguments for
using them in x86 are the same as ARM.
Julien/Stefano: Thoughts?
Using our own implementation rather than the built-in version gives us
the liberty to do optimization based on the processor using alternative.
I know that we already use built-in for arch_fetch_and_add, but I am
planning to revert that as we want to take advantage of new atomics
instruction in ARMv8.1.
Furthemore, someone mentioned a potential legal issue to linked against
the built-in. Anyone heard about that?
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
