Optimize Option::clone to Copy when possible #76551
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a pair of commits that attempt to improve the codegen of
Option::clone.
The first commit "specializes"
Option<T: Copy>::clone
to a memcpy. Forexample, as of this PR, cloning an
Option<[u8; 8]>)
branches on theOption's discriminant link. Copying
the bytes without a branch is more efficient.
The second commit adds the same optimization but specialized for Range.
Range<T: Copy> is famously not Copy (see #27186 and related); I do not
propose to necro that discussion but I would like to see a more efficient
clone(). Because Range is not Copy, this version uses unsafe
ptr::read
toachieve the same effect.
Note: the first commit has a user-visible behavior change in that
Option::clone() will no longer invoke T::clone() if T is Copy. This was
considered as OK in RFC 1521
but it might be worth calling out in release notes.