* Aaron Sawdey: > If you are aware of any real world code that is faster when built > with -fno-builtin-strcmp and/or -fno-builtin-strncmp, please let me know > so I can look at avoiding those situations.
Sorry, I have not tried to benchmark this. One more question: There's a hardware erratum on POWER9 DD2.1 related to VSX load instructions causing memory corruption when accessing cache-inhibited memory. It may not be very likely that strncmp is used on such memory, but memcpy and memmove definitely need to take that into account, and perhaps memset and memcmp as well. In the past, I did not receive positive feedback for my suggestion that we should have a separate family of string functions for device memory. (This is a general problem that is not specific to POWER.) So we still have the problem that at least some of the string functions in glibc need to be compatible with device memory. My concern here is that the GCC inline expansion could essentially disable the workaround we have in glibc memcpy and memmove for the hardware erratum. Thanks, Florian
