This is an archive of the discontinued LLVM Phabricator instance.

[FileCheck] - Refactor the code related to string arrays. NFCI.
ClosedPublic

Authored by grimar on Apr 15 2020, 6:35 AM.

Details

Summary

I've noticed that here are
few std::vector<std::string> members in FileCheckRequest,
though there is no reason not to use StringRef it seems.

This patch changes these arrays to std::vector<StringRef>
and refactors the code in callers to cleanup/improve/simplify
how it works with these arrays.

Diff Detail

Event Timeline

grimar created this revision.Apr 15 2020, 6:35 AM

Thanks for doing this. Looks much nicer, especially in the unit tests. A few suggestions to go further in that area.

llvm/unittests/Support/FileCheckTest.cpp
888–889

Move this below (see comment)

894–896

Fold first line into the second as you did above.

895–898

Ditto and remove the clear

900–902

Ditto

901–904

Ditto

906–908

Ditto

907–910

Ditto

912–915

Ditto

916–919

Ditto

922–923

Ditto

926

Remove and move the declaration of GlobalDefines here.

grimar updated this revision to Diff 257750.Apr 15 2020, 9:29 AM
grimar marked 11 inline comments as done.
  • Addressed review comments.
thopre accepted this revision.Apr 15 2020, 10:03 AM

LGTM

This revision is now accepted and ready to land.Apr 15 2020, 10:03 AM
MaskRay added a comment.EditedApr 15 2020, 10:07 AM

I am a bit concerned that some StringRefs come from the storage of cl::list<string>, and it is not entirely clear that those StringRefs will not get invalidated. (It will not if one knows the internals of cl::list but this is subtle and it'd be good to drop reliance of it.)

Other cleanups, look good, though.

  • auto -> concrete type
  • emplace_back(std::string(...)) -> emplace_back(...)
grimar added a comment.EditedApr 16 2020, 2:23 AM

I am a bit concerned that some StringRefs come from the storage of cl::list<string>, and it is not entirely clear that those StringRefs will not get invalidated. (It will not if one knows the internals of cl::list but this is subtle and it'd be good to drop reliance of it.)

The storage is destroyed when FileCheck terminates for me and with the current code it doesn't seem that any list_storage<DataType, bool> methods that can invalidate it are called/can be called before that.
But I agree that it is too subtle. I'll update the patch to improve this situation.

grimar updated this revision to Diff 258023.Apr 16 2020, 5:25 AM
  • Use BumpPtrAllocator to hold a copy of strings.
MaskRay added inline comments.Apr 16 2020, 8:34 AM
llvm/utils/FileCheck/FileCheck.cpp
568

--check-prefix, --implicit-check-not and -D are by no means performance/memory usage critical... Using a BumpPtrAllocator does not seem to improve the code ?

Can other cleanups in this patch be retained if you don't change the 3 variables to std::vector<StringRef>?

grimar marked an inline comment as done.Apr 17 2020, 1:32 AM
grimar added inline comments.
llvm/utils/FileCheck/FileCheck.cpp
568

I think having

std::vector<StringRef> CheckPrefixes;
std::vector<StringRef> ImplicitCheckNot;
std::vector<StringRef> GlobalDefines;

instead of

std::vector<std::string> CheckPrefixes;
std::vector<std::string> ImplicitCheckNot;
std::vector<std::string> GlobalDefines;

Improves the code by itself as readers should not think about why "std::string" was used.
We can revert to the previous revision of the patch as it works fine even without
adding a "BumpPtrAllocator".

grimar marked an inline comment as done.Apr 17 2020, 2:20 AM
grimar added inline comments.
llvm/utils/FileCheck/FileCheck.cpp
568

Also, for example this patch changes:

Error FileCheckPatternContext::defineCmdlineVariables(
    std::vector<std::string> &CmdlineDefines, SourceMgr &SM) {

to

Error FileCheckPatternContext::defineCmdlineVariables(ArrayRef<StringRef> CmdlineDefines,
                               SourceMgr &SM);

Using of std::string would require changing CmdlineDefines to be ArrayRef<std::string>,
i.e. std::string is spreading for no reason and the idea of this patch is to stop it.

grimar updated this revision to Diff 258496.EditedApr 18 2020, 2:25 AM

Thinking about it again I do not think that is *too* subtle to hold StringRef for options like
static cl::list<std::string> ImplicitCheckNot. They are static variables and expected to live the whole
time while application is running. It also would be strange for them to change after initialization,
hence:

  • Reverted to the previous version (without BumpPtrAllocator).
MaskRay accepted this revision.Apr 18 2020, 8:32 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptApr 20 2020, 5:20 AM