This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC][GCC][rs6000] Remaining work for inline expansion of strncmp/strcmp/memcmp for powerpc
- From: Florian Weimer <fweimer at redhat dot com>
- To: Aaron Sawdey <acsawdey at linux dot ibm dot com>
- Cc: gcc at gcc dot gnu dot org, Bill Schmidt <wschmidt at linux dot ibm dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>, mjw at fedoraproject dot org
- Date: Mon, 03 Dec 2018 15:34:57 +0100
- Subject: Re: [RFC][GCC][rs6000] Remaining work for inline expansion of strncmp/strcmp/memcmp for powerpc
- References: <c1513179-5aba-713b-32e7-3ce9c78cdb49@linux.ibm.com> <8736t4cmkh.fsf@mid.deneb.enyo.de> <8d7280f4-392a-e56b-380f-c7612f4bf670@linux.ibm.com>
* 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