This is an archive of the discontinued LLVM Phabricator instance.

[NFC] Class for building MultilibSet
ClosedPublic

Authored by michaelplatings on Jan 30 2023, 6:30 AM.

Details

Summary

The functionality in MultilibSet for creating it is tied to its current
implementation. Putting that code in a separate class is an enabler for
changing the MultilibSet implementation.

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptJan 30 2023, 6:30 AM
Herald added a subscriber: abrachet. · View Herald Transcript
michaelplatings requested review of this revision.Jan 30 2023, 6:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 30 2023, 6:30 AM
michaelplatings retitled this revision from Class for building MultilibSet to [NFC] Class for building MultilibSet.Feb 6 2023, 3:55 AM

Looks good so far. Some stylistic suggestions.

clang/include/clang/Driver/Multilib.h
25

It took a bit of reading to work out what the relationship between Multilib, MultilibVariant, MultilibSet and MultilibVariantBuilder are and how they are expected to be used.

IIUC MultilibVariant and MultilibVariantBuilder are used to construct Multilib and MultilibSet, which are expected to be immutable post construction.

Will be worth either a comment describing the relation ship or potentially write up the design in the clang docs and reference it from here.

45

Could be worth documenting the requirement for the strings to start with a / or be empty as the constructor implementation in a different file will assert if they aren't?

clang/lib/Driver/ToolChains/BareMetal.cpp
32–33

Worth making this a lambda in findRISCVMultilibs? Purely subjective opinion here as there could be an attempt to limit changes.

44–48

Wondering if we've lost information here by going to auto. We're really making a MultilibVariant here. Perhaps worth renaming makeMultilib to makeMultilibVariant?

clang/lib/Driver/ToolChains/Gnu.cpp
1049–1050

Similar comment to BareMetal, is it worth renaming to makeMultilibVariant

1759–1760

Although I'm not too bothered myself, some people prefer to keep changes in whitespace to a separate NFC patch for the benefit of git annotate.

michaelplatings marked 6 inline comments as done.

Apply improvements suggested by @peter.smith

clang/include/clang/Driver/Multilib.h
25

Yeah the naming was not intuitive, a hangover from one of the previous forms of this change. I've changed it so that MultilibBuilder creates Multilib and MultilibSetBuilder creates MultilibSet. That should make the comments less necessary, but I've added those too.

clang/lib/Driver/ToolChains/BareMetal.cpp
32–33

there could be an attempt to limit changes.

Indeed. I'd rather leave this in place for that reason.

44–48

I've gone back to declaring the type explicitly and renamed the function to makeMultilibBuilder since MultilibBuilder is the return type now.

clang/lib/Driver/ToolChains/Gnu.cpp
1049–1050

Renamed to makeMultilibBuilder since MultilibBuilder is the return type now.

1759–1760

git-clang-format insists on changing it. A removed line won't show up in git annotate/blame (unless you're doing some extreme reverse-blaming activity, which mostly people don't) so I think it's best to let git-clang-format do its thing.

phosek added inline comments.Feb 7 2023, 8:24 PM
clang/include/clang/Driver/Multilib.h
35–39

Since this class is intended to be immutable, we should also consider marking all fields as const. This can be done in a future refactoring, but it might be worth leaving a TODO here.

85

Since this class is intended to be immutable, and the number of Multilibs is known at construction time, we could use llvm::TrailingObjects instead of std::vector which would be more efficient. This can be done in a future refactoring, but it might be worth leaving a TODO here.

105–106

I don't think we should expose this method to maintain the invariant that MultilibSet is immutable post construction, instead this method should be provided by MultilibSetBuilder.

clang/lib/Driver/ToolChains/BareMetal.cpp
32–33

I'd suggest adding a single argument constructor to MultilibBuilder since this pattern is replicated across different files and so it makes sense to generalize but I agree that we can do that in a follow up change as a cleanup/refactor.

Replace makeMultilibBuilder() with a MultilibBuilder constructor that initializes all suffixes to the same value.

In the case of AndroidMipsMultilibs it was apparently intended that only the GCC suffix was set, and the other suffixes were left empty. This is now explicit in the code.

Comments about Multilib being "immutable" were overstated so I've now removed them. The intention is merely to remove the requirement to support mutation. The code is simpler when you don't need to keep checking invariants.

michaelplatings marked 4 inline comments as done.Feb 8 2023, 4:18 AM
michaelplatings added inline comments.
clang/include/clang/Driver/Multilib.h
35–39

Immutable was overstating it. I won't rule out that there may be a good reason to mutate it in future, but there's no need to actively support mutation now. I removed "immutable" from the comment.

85

Immutable was overstating it, and wasn't intended to apply to this class - a later change adds a parse() method which mutates in-place. I'm also sceptical of TODOs ever getting done - there are over 3,000 of them in llvm/lib alone :(

105–106

Immutable was overstating it, and wasn't intended to apply to this class - a later change adds a parse() method which mutates in-place. I did start off by removing push_back() but found it made the class less convenient to use.

clang/lib/Driver/ToolChains/BareMetal.cpp
32–33

I've gone ahead and added the constructor in this patch.

Thanks for the updates, I'm happy with the changes and don't have any more comments. Happy to give my implicit approval.

MaskRay added inline comments.Feb 10 2023, 10:49 PM
clang/include/clang/Driver/MultilibBuilder.h
118

Use camelCase for new function names.

phosek accepted this revision.Feb 14 2023, 1:16 AM

LGTM

clang/include/clang/Driver/MultilibBuilder.h
118

These functions were copies from the existing MultilibSet class so I'm fine keeping the original names to reduce the amount of changes. If we decide to change the names, it would ideally be done in a follow up change.

This revision is now accepted and ready to land.Feb 14 2023, 1:16 AM
This revision was automatically updated to reflect the committed changes.
michaelplatings marked 4 inline comments as done.