Vector128<T> is unnecessarily being left in a Blazor WASM default app

[eerhardt]

When publishing a Blazor WASM app, the Vector128<T> type is being left in the published app. The only method that is using it is:

runtime/src/libraries/System.Private.CoreLib/src/System/Text/Unicode/Utf8Utility.Transcoding.cs

Lines 881 to 889 in 40b0915

	// We have paths for SSE4.1 vectorization inside the inner loop. Since the below
	// vector is only used in those code paths, we leave it uninitialized if SSE4.1
	// is not enabled.
	Unsafe.SkipInit(out Vector128<short> nonAsciiUtf16DataMask);
	if (Sse41.X64.IsSupported || (AdvSimd.Arm64.IsSupported && BitConverter.IsLittleEndian))
	{
	nonAsciiUtf16DataMask = Vector128.Create(unchecked((short)0xFF80)); // mask of non-ASCII bits in a UTF-16 char
	}

We should try to refactor this code to not root the Vector128<T> Type in a Blazor WASM app.

Tagging subscribers to this area: @tarekgh, @krwq, @eiriktsarpalis, @layomia
See info in area-owners.md if you want to be subscribed.

Issue Details

---

When publishing a Blazor WASM app, the Vector128<T> type is being left in the published app. The only method that is using it is:

runtime/src/libraries/System.Private.CoreLib/src/System/Text/Unicode/Utf8Utility.Transcoding.cs

Lines 881 to 889 in 40b0915

	// We have paths for SSE4.1 vectorization inside the inner loop. Since the below
	// vector is only used in those code paths, we leave it uninitialized if SSE4.1
	// is not enabled.
	Unsafe.SkipInit(out Vector128<short> nonAsciiUtf16DataMask);
	if (Sse41.X64.IsSupported || (AdvSimd.Arm64.IsSupported && BitConverter.IsLittleEndian))
	{
	nonAsciiUtf16DataMask = Vector128.Create(unchecked((short)0xFF80)); // mask of non-ASCII bits in a UTF-16 char
	}

We should try to refactor this code to not root the Vector128<T> Type in a Blazor WASM app.

Author:	eerhardt
Assignees:	tannergooding
Labels:	area-System.Text.Encoding, size-reduction
Milestone:	-

[tannergooding]

I'll take a look at refactoring.

That being said, this also seems like a case where the linker could recognize that Unsafe.SkipInit is a nop and do the dead code elimination itself.
Methods in Unsafe are generally marked [NonVersionable] and so have special rules with regards to Crossgen that make it safe to do things like inline across version bubbles (https://github.com/dotnet/runtime/blob/1d9e50cb4735df46d3de0cee5791e97295eaf588/docs/design/features/crossgen2-compilation-structure-enhancements.md#behavior-of-code-that-shares-a-version-bubble).

If the linker properly supported this, then we could not only trim out Unsafe but also perform better optimizations in cases like this because we'd see that nonAsciiUtf16DataMask is unused and therefore dead code.

[tannergooding]

I logged dotnet/linker#1805 suggesting that the linker also handle this scenario.