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

Remove unneeded static_cast for xexp #3083

Merged
merged 2 commits into from
Sep 13, 2022
Merged

Conversation

AtariDreams
Copy link
Contributor

We can just check for 0 since -0 is just 0

We can just check for 0 since -0 is just 0
@AtariDreams AtariDreams requested a review from a team as a code owner September 7, 2022 13:01
@StephanTLavavej StephanTLavavej added the enhancement Something can be improved label Sep 7, 2022
@StephanTLavavej
Copy link
Member

Thanks!

  • I agree that this change is correct. xexp is a local variable and it isn't mentioned after this if-statement (or address-taken), so conditionally performing the assignment is unobservable.
  • The cast was presumably attempting to silence truncation warnings, because with short xexp, the expression -xexp triggers integer promotion, then assigning int to short may emit a truncation warning. However, this is in stl/src, and if the STL builds warning-free, there is no reason to have the cast here. (This may have been compiler-dependent, or the compiler may have gotten less aggressive about warning for expressions like val = -val;.)
  • I believe that this change is desirable primarily because it gets the assignment out of the condition, which is an overly complicated practice that we avoid in new code.

@StephanTLavavej StephanTLavavej added this to Final Review in Code Reviews Sep 7, 2022
@AtariDreams
Copy link
Contributor Author

I was actually considering making xexp an integer. All the tests pass if we make xexp an integer in this case and would certainly be faster to work on for RISC processors while also avoiding the problems of potentially needing casts.

However, I'm worried about tiny edge cases as I can't prove that at this point in execution, xexp is in range of a short, which would thereby change behavior, or if said behavior does change, whether such a change would have any adverse effect on the runtime.

So I decided to play it safe.

@StephanTLavavej
Copy link
Member

So I decided to play it safe.

Agreed, thanks.

I've pushed an additional commit, as I remembered to check for additional affected locations (the float/double codepaths are often similar like this). Double-checked that the change is still safe and desirable here.

@AraHaan
Copy link

AraHaan commented Sep 9, 2022

Is there other files with similar code as well?

@StephanTLavavej
Copy link
Member

I searched for other files and I think we've got them all now, although I could have missed something.

@strega-nil-ms strega-nil-ms moved this from Final Review to Ready To Merge in Code Reviews Sep 12, 2022
@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 0c9af46 into microsoft:main Sep 13, 2022
Code Reviews automation moved this from Ready To Merge to Done Sep 13, 2022
@StephanTLavavej
Copy link
Member

Thanks for this code cleanup! 😸 😸

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
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

5 participants