arm64: Rename SVE Prefetch APIs names to use Bit

[jonathandavies-arm]

• Fixes Arm64 SVE: Rename Prefetch APIs names to use Bit #114909

[a74nh]

@kunalspathak : Now that SVE exists in .NET9 and .NET10 do we have to do something special when changing the API names?

2025-05-15T13:50:31.1464888Z D:\a\_work\1\s\src\libraries\apicompat\ApiCompat.proj(93,5): error : API compatibility errors between 'net9.0/System.Runtime.Intrinsics.dll' (left) and 'net10.0/System.Runtime.Intrinsics.dll' (right):
2025-05-15T13:50:31.1474870Z D:\a\_work\1\s\src\libraries\apicompat\ApiCompat.proj(93,5): error CP0002: Member 'void System.Runtime.Intrinsics.Arm.Sve.PrefetchBytes(System.Numerics.Vector<byte>, void*, System.Runtime.Intrinsics.Arm.SvePrefetchType)' exists on net9.0/System.Runtime.Intrinsics.dll but not on net10.0/System.Runtime.Intrinsics.dll
2025-05-15T13:50:31.1477545Z D:\a\_work\1\s\src\libraries\apicompat\ApiCompat.proj(93,5): error CP0002: Member 'void System.Runtime.Intrinsics.Arm.Sve.PrefetchInt16(System.Numerics.Vector<ushort>, void*, System.Runtime.Intrinsics.Arm.SvePrefetchType)' exists on net9.0/System.Runtime.Intrinsics.dll but not on net10.0/System.Runtime.Intrinsics.dll
2025-05-15T13:50:31.1491490Z D:\a\_work\1\s\src\libraries\apicompat\ApiCompat.proj(93,5): error CP0002: Member 'void System.Runtime.Intrinsics.Arm.Sve.PrefetchInt32(System.Numerics.Vector<uint>, void*, System.Runtime.Intrinsics.Arm.SvePrefetchType)' exists on net9.0/System.Runtime.Intrinsics.dll but not on net10.0/System.Runtime.Intrinsics.dll
2025-05-15T13:50:31.1508773Z D:\a\_work\1\s\src\libraries\apicompat\ApiCompat.proj(93,5): error CP0002: Member 'void System.Runtime.Intrinsics.Arm.Sve.PrefetchInt64(System.Numerics.Vector<ulong>, void*, System.Runtime.Intrinsics.Arm.SvePrefetchType)' exists on net9.0/System.Runtime.Intrinsics.dll but not on net10.0/System.Runtime.Intrinsics.dll
2025-05-15T13:50:31.1636343Z D:\a\_work\1\s\src\libraries\apicompat\ApiCompat.proj(93,5): error : API breaking changes found. If those are intentional, the APICompat suppression file can be updated by rebuilding with '/p:ApiCompatGenerateSuppressionFile=true'

[kunalspathak]

LGTM

[kunalspathak]

what is the purpose of adding this file?

[kunalspathak]

@tannergooding - can you double check the changes in ApiCompatBaseline?

[kunalspathak]

/ba-g failures are unrelated

[dotnet-policy-service]

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

[ericstj]

I marked this as breaking since it changed the method name. This is binary breaking for folks moving from .NET 9.0 to 10.0. @tannergooding are we OK with that break? It will mean libraries built against 9.0 will fail at runtime if they use these methods.

[ericstj]

Correction, @kunalspathak let me know this was in experimental API - which is OK. That's an expected risk folks take using experimental API. Your call if you'd like to document this as breaking or not.

@gewarren - anything special that needs to happen in this case to clean up API docs for these renamed methods? I'm guessing the system is not going to just discover that these are removed.

[gewarren]

@ericstj I logged an issue to add remarks about the new method names. The old methods will appear when .NET 9 is selected and disappear when .NET 10 is selected.