Fix BigInteger.LeadingZeroCount, PopCount, TrailingZeroCount, RotateLeft, and RotateRight for platform-independent 32-bit word semantics

[Copilot]

After the _bits migration from uint[] to nuint[] (#125799), several IBinaryInteger<BigInteger> methods returned platform-dependent results. This PR restores consistent 32-bit word semantics for all five affected methods, including both the _sign path and the _bits path.

Description

Changes

LeadingZeroCount:

• _sign path: nint.LeadingZeroCount → uint.LeadingZeroCount((uint)value._sign)
• _bits path: BitOperations.LeadingZeroCount(value._bits[^1]) & 31 to map to 32-bit word semantics

PopCount:

• _sign path: nint.PopCount(value._sign) → int.PopCount(value._sign)
  • Fixes PopCount(-1) returning 64 on 64-bit vs 32 on 32-bit
• _bits negative path: Replace inline two's complement with formula PopCount(2^W - m) = W - PopCount(m) - TZC(m) + 1 using 32-bit word width W
  • Fixes ~(nuint) filling upper 32 bits with 1s on 64-bit when magnitude only uses lower 32 bits

TrailingZeroCount:

• _sign path: nint.TrailingZeroCount(value._sign) → int.TrailingZeroCount(value._sign)
  • Fixes TrailingZeroCount(BigInteger.Zero) returning 64 on 64-bit vs 32 on 32-bit

RotateLeft:

• _sign path: BitOperations.RotateLeft((nuint)value._sign, rotateAmount) → uint.RotateLeft((uint)value._sign, rotateAmount) with new BigInteger((int)rs) / new BigInteger(rs) result construction
  • Fixes RotateLeft(BigInteger.One, 32) returning 2^32 on 64-bit vs 1 on 32-bit
• _bits path: Rewrote Rotate() helper to use MemoryMarshal.Cast<nuint, uint> to get a Span<uint> view of the result nuint[] buffer, perform all rotation logic directly on 32-bit words, with big-endian support via half-word swapping within each limb before and after the 32-bit operations

RotateRight:

• _sign path: BitOperations.RotateRight((nuint)value._sign, rotateAmount) → uint.RotateRight((uint)value._sign, rotateAmount) with new BigInteger((int)rs) / new BigInteger(rs) result construction
  • Fixes RotateRight(BigInteger.One, 1) returning 2^63 on 64-bit vs 2^31 on 32-bit
• _bits path: Same Rotate() rewrite as RotateLeft (shared helper)

Endianness safety: The Rotate() helper uses MemoryMarshal.Cast<nuint, uint> to obtain a Span<uint> view of the nuint[] buffer. On big-endian 64-bit platforms, the two 32-bit halves within each nuint limb are swapped before performing 32-bit word operations, then swapped back after — ensuring correct word order regardless of endianness. On 32-bit platforms, nuint and uint are the same size so no decomposition is needed.

Performance optimization: The Rotate() helper works directly in the final result nuint[] buffer allocated via RentedBuffer, avoiding any temporary uint[] array allocation. Input limbs are copied once into the result buffer, then all two's complement conversion, rotation, and sign-bit operations are performed in-place on the Span<uint> view. The SwapUpperAndLower32 helper also uses RentedBuffer for its temporary storage instead of ArrayPool<uint>, maintaining consistency with the rest of the BigInteger codebase.

SIMD optimizations: The LeftShiftSelf32 and RightShiftSelf32 helpers include full Vector512<uint>, Vector256<uint>, and Vector128<uint> acceleration matching the pattern used by the existing LeftShiftSelf/RightShiftSelf (nuint versions). This ensures large BigInteger rotations retain the same SIMD-accelerated shift performance as before the 32-bit word migration.

BigIntegerCalculator helpers:

• Added RotateLeft32 / RotateRight32 operating on Span<uint> with 32-bit shift arithmetic
• Added LeftShiftSelf32 / RightShiftSelf32 for bit-level shifts on uint spans with Vector128/256/512 SIMD acceleration
• Removed dead nuint-based RotateLeft/RotateRight/SwapUpperAndLower that were superseded by the uint-based versions
• Retained LeftShiftSelf/RightShiftSelf (nuint versions) which are still used by the general <</>> shift operators

Other methods verified: Log2 is NOT affected — the platform dependencies in BitsPerLimb and BitOperations.LeadingZeroCount cancel each other out, producing correct results on both platforms.

Tests: Comprehensive test coverage added/updated for all five methods:

• BigIntegerTests.GenericMath.cs: Updated RotateLeftTest/RotateRightTest with platform-independent assertions and additional _sign path coverage; added mixed-bit negative multiword PopCount tests (e.g., -(2^64 + 3), -(2^64 + 4), -(2^65 + 12), -(2^33 + 5)) to exercise the formula with non-trivial magnitudePopCount and magnitudeTZC simultaneously
• Rotate.cs: Fixed NegativeNumber_TestData and PowerOfTwo tests to use bpl = 32 instead of nint.Size * 8, fixed helper methods to use 4-byte alignment instead of nint.Size, fixed (nint)(-1) → (int)(-1) cast
• MyBigInt.cs: Fixed RotateLeft test reference implementation to pad to 4-byte boundaries instead of nint.Size
• All 3031 tests pass with zero failures

---

⌨️ Start Copilot coding agent tasks without leaving your editor — available in VS Code, Visual Studio, JetBrains IDEs and Eclipse.

[dotnet-policy-service]

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

[stephentoub]

@tannergooding, is the .NET 10 behavior that uses the upper 32-bit word what we want?

[Copilot]

Pull request overview

This PR restores platform-independent, 32-bit word–based semantics for BigInteger.LeadingZeroCount after the internal _bits storage migrated from uint[] to nuint[], and adds/updates tests to lock in the intended behavior.

Changes:

• Update BigInteger.LeadingZeroCount to always compute LZC using 32-bit word semantics (including on 64-bit platforms).
• Fix existing generic-math test expectations to be platform-independent (32/31 for Zero/One).
• Add a dedicated LeadingZeroCountTests suite and include it in the Numerics test project.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
src/libraries/System.Runtime.Numerics/src/System/Numerics/BigInteger.cs	Adjusts LeadingZeroCount to use 32-bit word semantics for both _sign and _bits representations.
src/libraries/System.Runtime.Numerics/tests/BigIntegerTests.GenericMath.cs	Updates assertions to expect platform-independent results for LeadingZeroCount(Zero/One).
src/libraries/System.Runtime.Numerics/tests/BigInteger/LeadingZeroCountTests.cs	Adds coverage for boundary and platform-independence scenarios (small/large, positive/negative).
src/libraries/System.Runtime.Numerics/tests/System.Runtime.Numerics.Tests.csproj	Includes the newly added LeadingZeroCountTests.cs in the test build.

Comments suppressed due to low confidence (1)

src/libraries/System.Runtime.Numerics/tests/BigInteger/LeadingZeroCountTests.cs:67

• Same as above: this parse call would be clearer and more consistent with the surrounding test suite if it used using System.Globalization; + NumberStyles.HexNumber instead of the Globalization. qualifier.

            // Parse the magnitude as a positive hex value (leading zero keeps high bit clear),
            // then negate it so the result is negative and stored in _bits.
            BigInteger magnitude = BigInteger.Parse(hexMagnitude, Globalization.NumberStyles.HexNumber);
            BigInteger value = -magnitude;

[stephentoub]

@copilot also address RotateLeft/RotateRight and any other similarly affected methods on BigInteger. Ensure comprehensive tests are added/updated in a manner consistent with the other APIs in this PR.

[Copilot]

@copilot also address RotateLeft/RotateRight and any other similarly affected methods on BigInteger. Ensure comprehensive tests are added/updated in a manner consistent with the other ...

Fixed RotateLeft and RotateRight _sign paths in d9749d7 — replaced BitOperations.RotateLeft/Right((nuint)value._sign, ...) with uint.RotateLeft/Right((uint)value._sign, ...) and updated result construction to use (int)rs/(uint)rs. Updated all platform-dependent test assertions (nint.Size * 8 expressions → fixed 32-bit values) and added comprehensive tests for _sign path values.

I also verified that Log2 is NOT affected — the platform dependencies in BitsPerLimb and BitOperations.LeadingZeroCount cancel each other out, producing correct results on both platforms.

Note: The pre-existing Rotate.cs tests (RunSmallTests, RunRotateTests) fail because the _bits path Rotate() helper also has platform-dependent behavior when operating on nuint[] limbs (e.g., two's complement conversion sign-extends differently on 64-bit). This is a broader issue separate from the _sign path fixes in this PR.

[stephentoub]

Note: The pre-existing Rotate.cs tests (RunSmallTests, RunRotateTests) fail because the _bits path Rotate() helper also has platform-dependent behavior when operating on nuint[] limbs (e.g., two's complement conversion sign-extends differently on 64-bit). This is a broader issue separate from the _sign path fixes in this PR.

@copilot, can you elaborate? If it wasn't platform-dependent before #125799, then I need you to fix it in this PR.

[stephentoub]

@copilot address the feedback in #126259 (comment). In particular, anywhere SIMD was previously being used, it must still be used, at least for 64-bit and little endian (if doing so more generally is challenging for some reason).

[Copilot]

@copilot address the feedback in #126259 (comment). In particular, anywhere SIMD was previously being used, it must still be used, a...

Added SIMD (Vector128/256/512) optimizations to LeftShiftSelf32 and RightShiftSelf32 in 7d1b36c. The SIMD pattern is structurally identical to the existing LeftShiftSelf/RightShiftSelf (nuint versions) but uses Vector<uint> instead of Vector<nuint>. This works on all platforms (including BE) since Vector<uint> element-wise shifts are endianness-independent. All 3031 tests pass.

[github-actions]

🤖 Copilot Code Review — PR #126259

Note

This review was generated by Copilot (Claude Opus 4.6) and cross-validated with GPT-5.4.

Holistic Assessment

Motivation: Justified and real. After the uint[] → nuint[] internal storage migration (PR #125799), the IBinaryInteger bit-manipulation operations (LeadingZeroCount, PopCount, TrailingZeroCount, RotateLeft, RotateRight) became platform-dependent — returning different results on 32-bit vs 64-bit. For example, PopCount(-1) returned 32 on 32-bit but 64 on 64-bit; LeadingZeroCount(0) returned 32 vs 64. This PR correctly restores platform-independent 32-bit word semantics.

Approach: Sound and well-executed. The PR consistently fixes all five affected operations to use 32-bit word semantics. Key techniques include the elegant & 31 mask for LeadingZeroCount, a mathematically correct formula for negative PopCount, and a full rewrite of Rotate to work on Span<uint> views via MemoryMarshal.Cast. The SIMD optimizations in the new LeftShiftSelf32/RightShiftSelf32 follow the same proven pattern as the existing nuint-based variants.

Summary: ✅ LGTM. Both independent analyses (Claude Opus 4.6 and GPT-5.4) confirmed correctness across all changed operations. No blocking issues found. The code is well-tested with comprehensive assertions covering _sign and _bits paths, positive/negative values, and platform-independence invariants.

---

Detailed Findings

✅ LeadingZeroCount — & 31 trick is correct

The _sign path changes nint.LeadingZeroCount → uint.LeadingZeroCount, correctly treating the 32-bit _sign field as a 32-bit word.

The _bits path uses BitOperations.LeadingZeroCount(value._bits[^1]) & 31. On 64-bit, when the MSL's upper 32 bits are zero, the 64-bit LZC is 32 + uint_lzc; the & 31 correctly maps this to uint_lzc. When the upper 32 bits are non-zero, LZC is already in [0, 31] and & 31 is a no-op. On 32-bit, LZC is always in [0, 31] (since bits[^1] is never zero for a valid BigInteger), so & 31 is also a no-op. Verified with representative values: 0x00000001 → 63 & 31 = 31 ✓, 0x80000000 → 32 & 31 = 0 ✓.

✅ PopCount — Formula is mathematically correct

The negative PopCount path replaces the old inline two's complement approach (which was buggy on 64-bit because ~(nuint) fills upper 32 bits with 1s) with the identity:

PopCount(2^W − m) = W − PopCount(m) − TZC(m) + 1

where W = wordCount × 32 is the total bit-width in 32-bit words. Verified with multiple examples:

• −(2^32) on 64-bit: _bits = [0x100000000], wordCount=2, result = 64−1−32+1 = 32 ✓
• −(2^64) on 64-bit: _bits = [0, 1], wordCount=3, result = 96−1−64+1 = 32 ✓

The magnitudePopCount and magnitudeTZC are computed in a single pass and are representation-independent (same result regardless of nuint limb size), while wordCount correctly counts significant 32-bit words by checking the MSL's upper half on 64-bit.

✅ TrailingZeroCount — Platform-independent despite using BitsPerLimb

The _sign path changes nint.TrailingZeroCount → int.TrailingZeroCount, fixing TZC(0) from 64→32 on 64-bit.

The _bits path adds BitsPerLimb (32 or 64) per zero limb. This gives identical results across platforms because each zero 64-bit limb represents exactly two zero 32-bit words (64 zero bits), matching the combined count. Verified: 2^32 gives TZC=32 on both 32-bit ([0x0, 0x1]: 32+0) and 64-bit ([0x100000000]: TZC=32).

✅ RotateLeft/RotateRight — Correct 32-bit word semantics

The _sign path correctly uses uint.RotateLeft/uint.RotateRight instead of the platform-dependent BitOperations.RotateLeft((nuint)...).

The _bits path rewrites Rotate() to: (1) compute 32-bit word count, (2) create a Span<uint> view via MemoryMarshal.Cast, (3) perform two's complement conversion on uint words, (4) call RotateLeft32, and (5) convert back. Big-endian 64-bit is handled by swapping uint halves within each nuint limb before and after the cast.

✅ SIMD in LeftShiftSelf32/RightShiftSelf32 — Carry propagation is correct

Both GPT-5.4 and I independently verified the SIMD/scalar boundary carry chain. The SIMD approach computes each element's result independently from its own original value and its neighbor's original value (loaded via an overlapping vector read), so no sequential carry propagation is needed. The scalar cleanup loop starts with carry2 = 0 which is correct because: (a) element 0 has no carry-in, and (b) the SIMD region already read the scalar elements' original values for its carries. This matches the established pattern in the existing LeftShiftSelf/RightShiftSelf nuint-based variants.

✅ No removed-method breakage

Grep confirmed zero remaining callers of the old RotateLeft(Span<nuint>), RotateRight(Span<nuint>), and SwapUpperAndLower(Span<nuint>) methods. The old nuint-based LeftShiftSelf/RightShiftSelf are still used by the general shift operators and remain intact.

✅ Tests — Comprehensive coverage

Tests cover both _sign (small values) and _bits (large values) paths for all five operations. Platform-independence invariants are explicitly asserted. The Rotate.cs and MyBigInt.cs test helpers correctly use fixed 32/4 constants instead of the old nint.Size * 8/nint.Size.

💡 Test coverage — Mixed-bit negative multiword case

(Flagged by both models) The negative PopCount tests mostly use powers-of-two magnitudes. A mixed-bit case like −(2^64 + 3) would exercise the formula with non-trivial magnitudePopCount and magnitudeTZC simultaneously, further locking in the formula's correctness. This is a follow-up suggestion, not a blocker.

💡 SIMD additions — No benchmark evidence

The new SIMD paths in LeftShiftSelf32/RightShiftSelf32 don't come with benchmark data. However, they're structurally identical to the existing SIMD code in the nuint-based LeftShiftSelf/RightShiftSelf which is already proven in the codebase, so the risk is minimal. A follow-up benchmark could confirm the benefit for large BigInteger rotations.

Generated by Code Review for issue #126259 · ◷

[stephentoub]

@copilot why is ArrayPool better than RentedBuffer here?

[Copilot]

It's not — that was an oversight when converting from Span<nuint> to Span<uint>. Fixed in 05ce40b to use RentedBuffer (via MemoryMarshal.Cast<nuint, uint>) which provides inline stack storage for small sizes, matching the original pattern.

[Copilot]

It's not — that was an oversight. Fixed in 05ce40b to use RentedBuffer (via MemoryMarshal.Cast<nuint, uint>) which provides inline stack storage for small sizes, matching the pattern used elsewhere in BigInteger.

[stephentoub]

@copilot address the testing gaps mentioned in #126259 (comment).

[Copilot]

@copilot address the feedback in #126259 (comment). In particular, anywhere SIMD was previously being used, it must still be used, a...

SIMD was addressed in 7d1b36c — LeftShiftSelf32 and RightShiftSelf32 now have full Vector128/256/512 acceleration matching the existing LeftShiftSelf/RightShiftSelf (nuint versions). Additionally, the ArrayPool<uint> in SwapUpperAndLower32 was replaced with RentedBuffer in 05ce40b per the review feedback.

[Copilot]

@copilot address the testing gaps mentioned in #126259 (comment).

Added mixed-bit negative multiword PopCount tests in 2357508. These exercise the formula PopCount(2^W - m) = W - PopCount(m) - TZC(m) + 1 with non-trivial magnitudePopCount and magnitudeTZC simultaneously:

• -(2^32 + 7): PopCount(m)=4, TZC(m)=0 → 61
• -(2^33 + 5): PopCount(m)=3, TZC(m)=0 → 62
• -(2^64 + 3): PopCount(m)=3, TZC(m)=0 → 94
• -(2^64 + 4): PopCount(m)=2, TZC(m)=2 → 93
• -(2^65 + 12): PopCount(m)=3, TZC(m)=2 → 92

All 3031 tests pass.