Arm64 2.1.x release

[sdmaclea]

Looking at the number of open arm64 issues, the availability of resources, the 2.1.0 release schedule...

It looks like linux-arm64 will not be ready in time for 2.1.0. Not giving up yet, but need to plan so that arm64 2.1.x is possible.

@dotnet/arm64-contrib

[sdmaclea]

Regarding HW Intrinsics:

Initial SIMD HW Intrinsic API is incomplete. Needs to add LoadVector*, Store(Vector*), and StaticCast<>()
ABI Handling is incomplete and broken. This is showing up in Stress testing.

My proposal here is to add the new functions to the CoreFX ABI, but disable the HW intrinsics feature until it is functionally complete and stable 2.1.y. This allows a complete set of intrinsics to be available for developers when they are usable.

Regarding SIMD:

While this is more functionally complete, some of the recent stress testing indicates ABI issues affecting HW Intrinsics are affecting SIMD as well. We may want to consider disabling SIMD.

@CarolEidt @eerhardt @RussKeldorph @tannergooding @4creators

[sdmaclea]

@jkotas @richlander @RussKeldorph

It is my expectation that arm64 enablement and stabilization work can continue after ZBB and/or initial release targeting release_2.1 servicing.

[4creators]

Initial SIMD HW Intrinsic API is incomplete. Needs to add LoadVector*, Store(Vector*)

These APIs are not critical for enabling Arm intrinsics as they can be replaced by Unsafe.Read/Write providing they will be capable to use proper CPU instructions.

I do not know if Unsafe casts would work as a replacement to StaticCast on Arm.

My proposal here is to add the new functions to the CoreFX ABI, but disable the HW intrinsics feature until it is functionally complete and stable 2.1.y

It is good proposal as real life code testing of feature is very important for reaching final stability and efficiency, however, I have some worries about security of such solution and perhaps it would be necessary to throw PNSE for every intrinsic available in S.P.C from RyuJIT to prevent any misuse.

[sdmaclea]

See also dotnet/cli#8896 (comment)

[jkotas]

It is my expectation that arm64 enablement and stabilization work can continue after ZBB and/or initial release targeting release_2.1 servicing.

It can definitely continue in master.

We limit churn in servicing branches to manage risk. I do not think we can promise that the churn required to make arm64 work great will be acceptable for 2.1.x servicing branch. We can have that discussion once we get there.

cc @Petermarcu

[sdmaclea]

@jkotas @Petermarcu It would be nice to at least have a CoreCLR 2.1.arm64 branch so we can stabilize for arm64. The fact that it is stable for x64 should drastically help in arm64 stabilization. Once arm64 is stable we can look at merging to the 2.1.stabilization branch.

[sdmaclea]

The delay of the the 'last' integration of master to release 2.1 to 4/13 was a win.

There are two Linux-arm64 PRs (#17508 dotnet/coreclr#17536) which have not yet merged, but will resolve the major stability issues.

[sdmaclea]

The dotnet/coreclr#17508 was abandoned in lieu of dotnet/coreclr#17567. Both dotnet/coreclr#17536 and dotnet/coreclr#17567 have merged.

Overall the state of the linux-arm64 release candidate is in good shape.

Ignoring stress failures there are only a few failing tests between coreclr and corex.

• crossgen failures running r2r [Arm64] Crossgen of ConsoleMandel.exe fails #9798 & [Arm64] Crossgen of VectorReturn_r & VectorReturn_ro fails #9799. -- @debayan has opened [Arm64] Disable SIMD in crossgen (added as part of #14633) coreclr#17575. These will be reviewed and possibly championed by @RussKeldorph in ask mode per @jkotas
• System.Reflection.Emit.ILGeneration.Tests fails -- This is a hard failure in default mode, so I plan to root cause and draft a fix. Fix will likely impact arm64 assembly only.
• System.ValueTuple.Tests fails -- This is a hard failure in default mode, so I plan to root cause and draft a fix.

Regarding stress failures. There are a handful of repeatable stress failures. #9615, #9721, #9795, #9991, #10001, #10002, #10023, dotnet/coreclr#17480. These will probably not meet the bug bar. I will probably fix all of these on master before deciding whether to ask for any of them in 2.1.

[sdmaclea]

It has been decided that arm64 will not be officially released with the 2.1 release.

The release will be at least deferred until 2.2.

Closing for 2.1