This PR creates an SVE-based implementation for strlen by translating from the AOR code in tree. Microbenchmark shows improvements against NEON when N>=64. Although both implementations fall behind glibc by a large margin, this may be a good start point to explore SVE implementations. Together with the PR: 1. Added two more tests of strlen with special nul symbols. 2. Added strlen's fuzzer and fix a typo in previous heap fuzzer. ``` === strlen(16 bytes) === libc: 1.56115 ns/call, 9.54499 GiB/s neon: 1.59393 ns/call, 9.34867 GiB/s sve: 1.66097 ns/call, 8.97134 GiB/s === strlen(64 bytes) === libc: 2.06967 ns/call, 28.7991 GiB/s neon: 2.59914 ns/call, 22.9325 GiB/s sve: 2.58628 ns/call, 23.0465 GiB/s === strlen(256 bytes) === libc: 3.74165 ns/call, 63.7202 GiB/s neon: 8.98243 ns/call, 26.5428 GiB/s sve: 7.36426 ns/call, 32.3751 GiB/s === strlen(1024 bytes) === libc: 10.5327 ns/call, 90.5438 GiB/s neon: 34.363 ns/call, 27.7529 GiB/s sve: 26.9329 ns/call, 35.4092 GiB/s === strlen(4096 bytes) === libc: 37.7304 ns/call, 101.104 GiB/s neon: 145.911 ns/call, 26.144 GiB/s sve: 103.208 ns/call, 36.9612 GiB/s === strlen(1048576 bytes) === libc: 9623.4 ns/call, 101.478 GiB/s neon: 36138.2 ns/call, 27.023 GiB/s sve: 26605.6 ns/call, 36.7051 GiB/s ```
docgen relies on the convention that we have a file foo.cpp in libc/src/\<header\>/. Because the above functions weren't in libc/src/strings/ but rather libc/src/string/, docgen could not find that we had implemented these. Rather than add special carve outs to docgen, let's fix up our sources for these 7 functions to stick with the existing conventions the rest of the codebase follows. Link: #118860 Fixes: #118875
This is step 4 of https://discourse.llvm.org/t/rfc-customizable-namespace-to-allow-testing-the-libc-when-the-system-libc-is-also-llvms-libc/73079
Reviewed By: sivachandra Differential Revision: https://reviews.llvm.org/D84611
splits it into two by using the value of the first byte to determine the length of the first string. Reviewed-by: PaulkaToast, Differential Revision: https://reviews.llvm.org/D82427 Summary: [libc] Since only one input is given, it is necessary to split the string into two containers so that they can be compared for the purposes of this fuzz test. This is done in the following manner: 1. Take the value of the first byte; this is size1. (Credits to @PaulkaToast for this idea). 2. size2 is the value of size - size1. 3. Copy the characters to new containers, data1 and data2 with corresponding sizes. 4. Add a null terminator to the first container, and verify the second container has a null terminator. 5. Verify output of strcmp. A simpler alternative considered was simply splitting the input data into two, but this means the two strings are always within +- 1 character of each other. This above implementation avoids this. ninja check-libc was run; no issues. Reviewers: PaulkaToast, sivachandra Reviewed By: PaulkaToast Subscribers: mgorny, tschuett, ecnelises, libc-commits, PaulkaToast Tags: #libc-project Differential Revision: https://reviews.llvm.org/D82427
Summary: Adds a fuzz test for string comparison. This takes in two strings with associated lengths. Verifies each string contains at least one character, and that the last character is the null terminator. Then, finds the first instance where one of the following does not hold: 1. i < min(size1, size2) 2. s1[i] == s2[i] 3. s1[i] != '\0' The result of strcmp is then compared to the value of the difference between s1[i] and s2[i]. For thoroughness, the operands are reversed and also checked. Reviewers: sivachandra, PaulkaToast Reviewed By: sivachandra, PaulkaToast Subscribers: mgorny, tschuett, ecnelises, libc-commits Tags: #libc-project Differential Revision: https://reviews.llvm.org/D82247
Reviewed-by: todo Differential Revision: https://reviews.llvm.org/D82247