-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
feature/spaceship: Clause 22: Containers #1046
feature/spaceship: Clause 22: Containers #1046
Conversation
This comment has been minimized.
This comment has been minimized.
52c7be9
to
8fcc25f
Compare
e56b1ba
to
81aff9b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this first batch of 🛸 work! I've reviewed everything and it looks solid; although some fixes are necessary, I think they should be relatively straightforward. (The biggest unknown is how to test synth-three-way
and I would be comfortable marking that as a FIXME
if you want.) Then it should be ready to be merged into the feature branch.
This comment has been minimized.
This comment has been minimized.
queue<T, NonSpaceshipContainer> might be instantiated for a non-three_way_comparable NonSpaceshipContainer. In that case, it shouldn't attempt to grant friendship to the spaceship operator, because that would attempt to form compare_three_way_result_t<NonSpaceshipContainer>. As far as I can tell, there's no way in the Core Language for a queue to grant friendship to only one specialization of its non-member spaceship operator while respecting the constraint. (See WG21-N4861 [temp.friend]/9.) Instead, we need to template the friendship declaration, such that queue grants friendship to all of its spaceship operators. This is safe, just verbose.
992b036
to
1dc5c43
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Testing `_Differing_bits == 0` might seem like it's asking the compiler to do more work (always XORing). But it allows the compiler to see that the input to `_Countr_zero` is nonzero, and that allows it to optimize away the runtime ISA check, unconditionally emitting a `tzcnt` instruction. Then, at the end of the function, we know something that the compiler doesn't realize: `_Mask` selects a differing bit (the least significant one), so `(_Left & _Mask)` and `(_Right & _Mask)` are zero/nonzero or vice versa. Therefore, we only need to inspect one side! I've verified that each of these changes improves the codegen. Co-authored-by: Casey Carter <[email protected]>
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two small suggestions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going to merge this into the feature branch after the tests run! 🎉 😸 🛸
I've added a note to the Spaceship Project that we need to implement spaceships for the container iterators too (which are Clause 22); that shouldn't hold up this significant PR.
Thanks for implementing the important |
This implements #62 for Clause 22, Containers.