Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[NFC] Make the GCData constructor a move constructor #6946

Merged
merged 5 commits into from
Sep 17, 2024

Conversation

kripken
Copy link
Member

@kripken kripken commented Sep 16, 2024

This avoids creating a large Literals (SmallVector of Literal) and then copying it. All the places
that construct GCData do not need the Literals afterwards.

Also add a few other constructor type things, all as a result of C++ compiler errors after
the GCData constructor change.

This gives a 7% speedup on the --precompute benchmark from #6931

auto allocation = std::make_shared<GCData>(type.getHeapType(), data);
//
// This consumes the input |data| entirely.
Literal makeGCData(Literals& data, Type type) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should change this to take Literals&& data to make it clearer in callers that data will be moved from.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh right, good idea. Done.

SmallVector(std::initializer_list<T> init) {
for (T item : init) {
push_back(item);
}
}
SmallVector(size_t initialSize) { resize(initialSize); }

SmallVector<T, N>& operator=(const SmallVector<T, N>& other) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add a move assignment operator for completeness?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, perhaps let's wait until there is a user? Otherwise adding it now would be dead/untested code.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is that if someone does try to use move assignment, the compiler will gracefully fall back to using copy assignment and the user will have no idea that they didn't get the move they wanted. We can prevent that by providing a move assignment operator eagerly, and the code should be simple enough that there shouldn't be any problems. (Alternatively we could provide a move assignment whose body is a WASM_UNREACHABLE.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, that does sound risky. Added.

@kripken kripken merged commit a99b48a into WebAssembly:main Sep 17, 2024
13 checks passed
@kripken kripken deleted the literal.move branch September 17, 2024 23:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants