Arm64 SVE: Allow SVE nodes to be treated as generic ops

[a74nh]

Enables all standard arithmetic operations.
Does not include compare operations.

[dotnet-policy-service]

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

[a74nh]

I plan on putting compares in a later PR as there is some extra debugging I need to do first.
Fuzzlyn looks clean over 3000 seconds.
A few small improvements with spmidiff. Although we weren't expecting much there as most of the current SVE tests/usage is not using constants.

[a74nh]

@tannergooding @EgorBo : I'm happy with this now

[JulieLeeMSFT]

We will review .NET 11 PRs when we are done with .NET 10 last minute works and less busy.
CC @dotnet/arm64-contrib.

[SwapnilGaikwad]

Hi @EgorBo , this PR slipped through our radar. Could you take a look at it, please?

[JulieLeeMSFT]

@EgorBo, PTAL.

[EgorBo]

Sorry for the delayed response, LGTM, let's run Fuzzlyn on this

[EgorBo]

/azp run Fuzzlyn

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This PR enables ARM64 SVE (Scalable Vector Extension) nodes to be treated as generic operations, allowing all standard arithmetic operations to be processed through the common value numbering and optimization paths. The changes align SVE intrinsics with existing AdvSimd intrinsics by mapping them to generic tree operations.

Key Changes

• Added mappings for 13 SVE intrinsics (And, Or, Xor, Not, BitwiseClear, Add, Subtract, Multiply, Divide, Negate, ShiftLeftLogical, ShiftRightArithmetic, ShiftRightLogical) to their corresponding generic tree operations
• Relaxed GT_AND_NOT assertions to allow this operation before lowering on ARM64 (needed for SVE BitwiseClear)
• Added ARM64-specific shift handling for "wide elements" variants using a new NarrowSimdLong template function
• Restructured conditional compilation to check for shift operations before platform-specific code paths

Reviewed changes

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

File	Description
src/coreclr/jit/gentree.cpp	Added SVE intrinsic to generic operation mappings and ARM64 shift narrowing logic; moved GT_AND_NOT assertion to be XARCH-specific
src/coreclr/jit/valuenum.cpp	Added ARM64 shift narrowing in value numbering; relaxed GT_AND_NOT assertions across three evaluation functions; restructured shift handling to be checked before platform-specific conditionals
src/coreclr/jit/simd.h	Added NarrowSimdLong template functions to handle narrowing of uint64_t vector elements to smaller types during shift operations

[tannergooding]

This looks like it might be missing some handling in gentree.cpp and lowerarmarch.cpp so that the transform of GT_AND(x, GT_NOT(y)) back into NI_Sve_BitwiseClear(x, y) can occur.

In particular, looks like we have a lack of handling in GetHWIntrinsicIdForBinOp and LowerHWIntrinsic where there is AdvSimd handling already. -- That is, we got NODE_ID -> GT_OP already, but the PR lacks support for the other direction: GT_OP -> NODE_ID

It's possible there is "more" work to be done here too, so that all the end to end transforms can light up, but that should be the bulk of it.

[a74nh]

This looks like it might be missing some handling in gentree.cpp and lowerarmarch.cpp so that the transform of GT_AND(x, GT_NOT(y)) back into NI_Sve_BitwiseClear(x, y) can occur.

In particular, looks like we have a lack of handling in GetHWIntrinsicIdForBinOp and LowerHWIntrinsic where there is AdvSimd handling already. -- That is, we got NODE_ID -> GT_OP already, but the PR lacks support for the other direction: GT_OP -> NODE_ID

It's possible there is "more" work to be done here too, so that all the end to end transforms can light up, but that should be the bulk of it.

What is happening right now is that it ends up with a NI_AdvSimd_Arm64_BitwiseClear` node:

• In impSpecialIntrinsic(), it uses gtNewSimdUnOpNode(GT_NOT...) and gtNewSimdBinOpNode(GT_AND....). Both of these will return an NI_AdvSimd_Arm64_... instrinsic.
• In LowerHWIntrinsic() because it's looking for GT_AND/GT_NOT there is no way to tell this is SVE specific.

In both cases, because the size is SIMD_16, I don't think it really matter that it creates a NEON node. And I think that forcing it to SVE would be quite messy, as there's no obvious check you can make for SVE in those cases (especially during lowering)

Once SVE is variable then yes we will need SVE nodes. I've added a few asserts on the sizes so that these are caught later down the line. Alternatively, we could pause this to post variable length SVE.