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

AreaZR
Copy link
Contributor

@AreaZR AreaZR commented Sep 7, 2022

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

We can just check for 0 since -0 is just 0
@AreaZR AreaZR 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.

@AreaZR
Copy link
Contributor Author

AreaZR commented Sep 8, 2022

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.

@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
@StephanTLavavej
Copy link
Member

Thanks for this code cleanup! 😸 😸

@AreaZR AreaZR deleted the int branch September 26, 2022 16:08
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.

5 participants