[release/11.0] Validate store-coalescing constants before modifying IR

[github-actions]

Backport of #133976 to release/11.0.

Validates store-coalescing constants before removing the previous store or widening the current store. Unsupported combinations now retain their original stores instead of leaving partially modified IR.

Customer Impact

• Customer reported
• Found internally

Incorrect JIT code generation can lose previously stored bytes or overwrite adjacent bytes with a sign-extended narrow constant. In #133746, Vector64.CreateScalar((sbyte)-1) produces <-1, -1, ...> instead of <-1, 0, ...> with DOTNET_EnableHWIntrinsic=0 and DOTNET_TieredCompilation=0. The same faulty rejection path also affects a narrow write over a Vector2 constant. Not taking the fix leaves silent incorrect results in affected optimized code.

Regression

• Yes
• No

Introduced during .NET 11 development by #126562 (commit 2a03681857007feda3c1f82d946ba8848c7350e2, merged April 27, 2026). That change added local-field store coalescing and fallible constant validation after IR mutation. The .NET 10 implementation does not have this local-field coalescing path or the post-mutation rejection checks; this is not a .NET 10 regression.

Testing

The original PR reports validation with a checked Windows x64 CoreCLR build, fixed JIT and cross-target JIT builds, both new regression variants, AVX2-disabled execution, and 16 existing struct-promotion tests. The Vector2 regression fails against the baseline JIT and passes with the fix. Coverage also checks negative and boundary signed values for Vector64.CreateScalar, with normal and hardware-intrinsics-disabled configurations. These tests exercise the previously uncovered constant-rejection path that could leave a store transformation partially applied.

Four existing coalescing-related methods had identical normalized disassembly before and after the fix (27, 55, 19, and 21 bytes). JIT formatting passed on the original change. The exact reported CreateScalar failure did not reproduce on the original validation host; ARM64 execution was not performed.

This backport matches the original PR's patches, apart from JIT hunk line numbers. No additional local build or execution was performed for the release branch; backport CI is pending.

Risk

Low. The product change moves existing scalar constant extraction and SIMD validation ahead of destructive IR mutation, without adding a new optimization or changing the existing packing and atomicity logic. Unsupported combinations preserve the original stores. Regression coverage verifies the failure mode, and the original PR's code-generation comparisons found no changes in the four sampled supported cases. The remaining validation limitation is the lack of ARM64 execution; release-branch CI still needs to complete.

IMPORTANT: If this backport is for a servicing release, please verify that:

• For .NET 8 and .NET 9: The PR target branch is release/X.0-staging, not release/X.0.
• For .NET 10+: The PR target branch is release/X.0 (no -staging suffix).

Verified target: dotnet/runtime, release/11.0.

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

Resolves #133746

Note

This backport description was drafted by 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.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[dhartglassMSFT]

lgtm backport matches the original bugfix

NET10->NET11 regression should meet the bar