Vectorize Base64 DecodeFromUtf8InPlace

[tannergooding]

Fixes #105707.

Base64.DecodeFromUtf8InPlace (and the Base64Url in-place decode) ran a pure scalar loop, unlike DecodeFrom which already had AVX-512 / AVX2 / AdvSimd / SSSE3 fast paths. That scalar loop is why the 200 MB Base64DecodeInPlace benchmark was ~395 ms, and why it was sensitive enough to layout that #105262 -- a correctness fix that only touched the once-per-call tail, leaving the hot loop's codegen byte-for-byte identical -- surfaced as a ~12% regression from alignment/layout alone.

This reuses the existing Avx512Decode / Avx2Decode / AdvSimdDecode / Vector128Decode helpers for the in-place path, mirroring DecodeFrom exactly. The decode is safe in place because the write cursor trails the read cursor by 25% (3 bytes written per 4 read), so each vector store -- including its zero-padded overshoot -- ends at or before the next vector load and never clobbers source that hasn't been read yet. The final overshoot of whichever path runs last lands strictly before the post-vector src, so the narrower SIMD phases and the scalar remainder read unclobbered data.

---

Measured locally on win-x64 (AVX-512 capable), 200 MB in-place decode, release runtime:

Config	Time	vs scalar
Scalar (DOTNET_EnableHWIntrinsic=0, prior behavior)	63.9 ms	1.0x
Vector128 (DOTNET_EnableAVX2=0)	24.4 ms	2.6x
AVX2/AVX-512	10.9 ms	5.9x

So this doesn't just recover the 12% regression -- it makes the in-place path ~2.6-5.9x faster depending on hardware.

---

Testing: all System.Memory.Tests pass (52,929) with the debug AssertRead/AssertWrite bounds checks active, including under DOTNET_EnableAVX2=0 and DOTNET_EnableHWIntrinsic=0. The existing EncodeAndDecodeInPlace test roundtrips every length 1-256, which exercises all in-place SIMD widths with byte-exact overlap validation. No JIT changes.

Note

This PR was authored with the assistance of GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[tannergooding]

This is libraries, not runtime related.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR updates the CoreLib Base64 in-place UTF-8 decoding implementation to use the existing SIMD-accelerated decode helpers (AVX-512 / AVX2 / AdvSimd / Vector128) that are already used by the non-in-place DecodeFrom path, improving throughput for large in-place decodes while preserving the existing scalar tail / padding validation behavior.

Changes:

• Add a SIMD fast path to Base64Helper.DecodeFromUtf8InPlace (guarded by #if NET) that reuses Avx512Decode / Avx2Decode / AdvSimdDecode / Vector128Decode.
• Update sourceIndex / destIndex based on the SIMD progress so the existing scalar loop and final-block handling continue correctly.

Show a summary per file

File	Description
src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Helper/Base64DecoderHelper.cs	Adds an in-place SIMD decode loop mirroring the existing DecodeFrom vectorized pipeline, then continues with the existing scalar remainder / padding validation.

Copilot's findings

• Files reviewed: 1/1 changed files
• Comments generated: 0