On 12/3/18 8:34 AM, Florian Weimer wrote:
> * 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.
I don't think we have a real concern here. DD2.1 is used in a particular
situation where GCC 4.8.5 is the supported compiler, and not used elsewhere.
So I'd prefer not to cripple the compiler for this specific use case. If
the customer with DD2.1 hardware chooses to use GCC 8 or later, and runs
into this problem, they can use -mno-builtin-mem{set,cmp} as a workaround.
Do you feel that's satisfactory?
We can also have a private discussion if you feel that's warranted.
Thanks,
Bill
>
> Thanks,
> Florian
>
