Skip to content

Remove unsafe code from Log2SoftwareFallback #118560

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

stephentoub
Copy link
Member

@stephentoub stephentoub requested a review from EgorBo August 10, 2025 02:09
@Copilot Copilot AI review requested due to automatic review settings August 10, 2025 02:09
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR removes unsafe code from the Log2SoftwareFallback method by replacing a manual unsafe memory access with a simple array indexing operation. The change simplifies the code while maintaining the same functionality for computing logarithm base 2 using a de Bruijn sequence lookup table.

Key Changes

  • Replaces Unsafe.AddByteOffset with direct array indexing
  • Removes unnecessary MemoryMarshal.GetReference call
  • Eliminates manual IntPtr casting

Copy link
Contributor

Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.

Copy link
Member

@tannergooding tannergooding left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be fine since all platforms have a baseline accelerated path.

We might, however, want to double check Mono to ensure that Arm and x64 isn't regressed for them.

The JIT could probably elide the bounds check itself here, but it would require it understanding that x >> 27 produces something where only the lower 5 bits can be set and so therefore must be in the range [0, 31]. Might be worth logging an issue for that as part of this.

@stephentoub
Copy link
Member Author

The JIT could probably elide the bounds check itself here, but it would require it understanding that x >> 27 produces something where only the lower 5 bits can be set and so therefore must be in the range [0, 31]. Might be worth logging an issue for that as part of this.

Isn't that what #109900 does?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants