This is an archive of the discontinued LLVM Phabricator instance.

[libc] Move str{,r}chr implementation to headers
ClosedPublic

Authored by abrachet on Apr 3 2023, 11:42 AM.

Diff Detail

Event Timeline

abrachet created this revision.Apr 3 2023, 11:42 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 3 2023, 11:42 AM
abrachet requested review of this revision.Apr 3 2023, 11:42 AM
abrachet added a child revision: D147464: [libc] Add {,r}index.

I'm not sure why this is necessary, given that only one function is calling the each of the strchr implementations, and they're each less than 10 lines of code. Do you plan to call these in more functions? If you are, would putting these implementations in string_utils.h make sense instead?

I'm not sure why this is necessary, given that only one function is calling the each of the strchr implementations, and they're each less than 10 lines of code. Do you plan to call these in more functions? If you are, would putting these implementations in string_utils.h make sense instead?

For child revision D147464. Regarding string_utils.h, why is that preferred over memory_utils/? I'm happy to do it, I forgot that header existed which is why I added it to string_utils. But I am curious why it is preferred

Generally, memory_utils/ is used for optimized memory functions and is managed by @gchatelet. The string_utils.h file has the implementations for functions focused on null terminated strings and is managed by me.

Given that the followup patch does add more uses for these functions, I see this as a worthwhile change, though I'd suggest making the internal function work like strchrnul. That will let you implement both strchrnul and strchr with the same internal function and only minor additional code.

Given that the implementations are small and standard C++ I would move them as part string_utils rather than memory_utils as @michaelrj suggested.

libc/test/src/string/StrchrTest.h
158

It'd rather see templated tests rather than macros. They tend to be harder to debug and they impede readability and formatting.
If you follow @michaelrj advice you won't have to duplicate the tests.

abrachet updated this revision to Diff 510839.Apr 4 2023, 9:27 AM
abrachet added inline comments.Apr 4 2023, 9:34 AM
libc/test/src/string/StrchrTest.h
158

Are you referring to gtest typed tests?

gchatelet added inline comments.Apr 5 2023, 1:37 AM
libc/test/src/string/StrchrTest.h
158
abrachet added inline comments.Apr 5 2023, 10:03 PM
libc/test/src/string/StrchrTest.h
158

I guess I don't understand how that would look like other than something like:

strchr_test.cpp
#define FUNC Strchr

struct FuncT {
  static constexpr auto Func = __llvm_libc::strchr;
};

#include "StrchrTest.h"

and

StrchrTest.h
#define TEST_NAME_(LEFT, MIDDLE, RIGHT) LEFT ## RIGHT
#define TEST_NAME(NAME) TEST_NAME_(LlvmLibc, NAME, Test)

TYPED_TEST(TEST_NAME(FUNC), FindsFirstCharacter, FuncT) {
  constexpr auto Func = ParamType::Func;

  const char *src = "abcde";

  // Should return original string since 'a' is the first character.
  ASSERT_STREQ(Func(src, 'a'), "abcde");
  // Source string should not change.
  ASSERT_STREQ(src, "abcde");
}
...

Which I don't think is better. Unless you have something else in mind. This is what parameterized tests are for, but we don't have those.

FWIW, the current code is how we already do these kinds of test sharing, mostly in math/.

I was thinking something along the lines of https://reviews.llvm.org/D147690

I was thinking something along the lines of https://reviews.llvm.org/D147690

I see. The reason I am partial to not doing that is because then to test strchr you must also include index, and it is very likely you would only want the former. I haven't included it in non linux targets, nor have I added it to the bazel build.

Moreover, the common structure of src/$func.{cpp,h} and test/src/$func_test.cpp makes downstream build infrastructure much easier when all functions follow the same pattern than multiple functions sharing a single test file.

ping

We would like to get D147464 landed soon

michaelrj accepted this revision.Apr 10 2023, 1:25 PM

While I like the idea of avoiding macros, I think it's more important for the tests to be independent of which entrypoints are included. This patch looks good to me.

This revision is now accepted and ready to land.Apr 10 2023, 1:25 PM
mcgrathr added inline comments.
libc/test/src/string/StrchrTest.h
158

TYPED_TEST is problematic since it's not supported by the other compatible-enough test frameworks where these tests are built, such as Fuchsia's zxtest. I think the tolerable middle ground that makes the boilerplate at least less annoying while avoiding macros is to rely on the fixture as done here to keep the actual test logic common and just template-parameterized with the actual function pointer, but then write out both copies of all the TEST_F(LlvmLibcStrchrTest, ...) and TEST_F(LlvmLibcIndexTest, ...). We can see in the future if using TYPED_TEST here can be made feasible, but it's just not yet.

I'd like to get this unblocked and land some version of this so we can get index and rindex landed.

This revision was landed with ongoing or failed builds.Apr 10 2023, 6:17 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptApr 10 2023, 6:17 PM

Sorry for the delayed response.
I missed the requirement that the tests should be independent. Given that the build system decides which functions are to be tested, it's difficult to use the templated approach I was suggested.

LGTM