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

Use a bitwise and instead of shifts #3092

Merged
merged 3 commits into from
Sep 13, 2022
Merged

Conversation

AreaZR
Copy link
Contributor

@AreaZR AreaZR commented Sep 8, 2022

This is faster in some instances and is clearer in intent

@AreaZR AreaZR requested a review from a team as a code owner September 8, 2022 14:36
@AreaZR AreaZR changed the title Use a bitwise instead of shifts Use a bitwise and instead of shifts Sep 8, 2022
This is faster in some instances and is clearer in intent
@StephanTLavavej StephanTLavavej added enhancement Something can be improved decision needed We need to choose something before working on this labels Sep 9, 2022
@StephanTLavavej
Copy link
Member

Thanks for looking into this!

The optimized codegen is identical: https://godbolt.org/z/K4envEYs5

I believe that the debug codegen is not important here - these are per-algorithm-call, and we generally don't worry about slightly suboptimal instruction sequences (whereas we occasionally worry about many layers of unnecessary function calls, e.g. in invoke()).

So the main question is clarity, which is a judgement call. I believe that the existing pattern of shifting back and forth by N more clearly expresses the intent to clear the low N bits. Marking as "decision needed" for the other maintainers to consider.

@MikeGitb
Copy link

Just a suggestion: If you want to use this notation, I'd use binary litterals instead of decimal numbers.

@AlexGuteniev
Copy link
Contributor

My opinion:

  • The clear way is * 16 / 16, though the debug codegen is expected to be awful (with actual division)
  • I'd wrote & 0xF. Hex is a compact binary.
  • There's no much point to make this clearer. Those who read SSE / AVX will not be confused by any of the opitions

@strega-nil-ms
Copy link
Contributor

I strongly agree that & ~... is more clear than >> N << N; however, I would also appreciate @AlexGuteniev's heximal literal change (or even binary literal). I'm not against making this clearer.

@StephanTLavavej StephanTLavavej removed the decision needed We need to choose something before working on this label Sep 12, 2022
Replacements:

_Byte_length(_First, _Last) >> 5 << 5
_Byte_length(_First, _Last) & ~size_t{0x1F}

_Byte_length(_First, _Last) >> 4 << 4
_Byte_length(_First, _Last) & ~size_t{0xF}
Replacements:

_Byte_length(_First, _Last) >> 6 << 5
(_Byte_length(_First, _Last) >> 1) & ~size_t{0x1F}

_Byte_length(_First, _Last) >> 5 << 4
(_Byte_length(_First, _Last) >> 1) & ~size_t{0xF}
@StephanTLavavej
Copy link
Member

Ok, I've validated and pushed changes to:

  • Use hex literals as suggested by @AlexGuteniev and @strega-nil-ms.
  • Use ~size_t{VALUE} to start with a constant of the desired width and avoid having to think about signed-to-unsigned conversions. (size_t & ~31 worked because ~31 is a negative int that gets sign-extended when converted to size_t, which I found highly surprising when I realized it.)
  • Also change >> 6 << 5 and >> 5 << 4.
    • I believe that this is a clarity improvement, as this makes the division by 2 (followed by masking) more obvious, so I am now in favor of this change.

Codegen is unaffected: https://godbolt.org/z/h7qE3vca1

Thanks again!

@StephanTLavavej StephanTLavavej self-assigned this Sep 12, 2022
@StephanTLavavej
Copy link
Member

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

@StephanTLavavej StephanTLavavej merged commit 5985b06 into microsoft:main Sep 13, 2022
@StephanTLavavej
Copy link
Member

Thanks for this code cleanup! 😸 😸 😸 😸 😸 😸 😸 😸

@AreaZR AreaZR deleted the bitwise-and branch September 26, 2022 16:06
CaseyCarter pushed a commit to CaseyCarter/STL that referenced this pull request Oct 6, 2022
Co-authored-by: Stephan T. Lavavej <stl@nuwen.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Something can be improved
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants