Use RuntimeHelpers.CreateSpan for array initialization with relevant primitives

[stephentoub]

The compiler currently optimizes array creation where:

• The array is immediately stored as a ReadOnlySpan<T> such that it's not exposed in any writeable manner
• The array is initialized entirely with constant values
• The element type is a single byte primitive (byte, bool, sbyte)

In such a situation, it creates a PrivateImplementationDetails field containing the data, and replaces the array creation with a span that points directly to the data on PrivateImplementationDetails.

This PR extends that optimization to multi-byte primitives: short, ushort, char, int, uint, long, ulong, float, and double. If the target platform has the RuntimeHelpers.CreateSpan method, it is used to handle endianness fixups. If the target platform lacks that method, the compiler emits code to cache the array in PrivateImplementationDetails and wrap a span around that lazily-initialized array.

[AlekseyTs]

@stephentoub We discourage force pushes and any forms of rewriting existing commits in branches that are already under review process. These operations confuse CodeFlow (the tool that we usually use for reviews) and prevent us from doing reviews in an incremental fashion. That is forcing us to start the review process from scratch after a change like that is performed. The recommended process is to keep pushing new commits into the branch, including merge commits, until PR is ready for merge, then doing a squash merge.

[stephentoub]

including merge commits

Most of the code this touches had to be rewritten in the face of the conflicting commit that got merged. I don't believe the effort required to review with a rebase or a merge would have been significantly different. But I will try to refrain from rebases in the future.

[MichalPetryka]

Would be nice if ReadOnlySpan<char> span = "text"; would also be optimized, since it's a much more convenient syntax for strings and would be analogous to the utf8 string feature.

[stephentoub]

Would be nice if ReadOnlySpan span = "text"; would also be optimized, since it's a much more convenient syntax for strings and would be analogous to the utf8 string feature.

What is it you'd hope it would do it's not already doing?
SharpLab

[MichalPetryka]

Would be nice if ReadOnlySpan span = "text"; would also be optimized, since it's a much more convenient syntax for strings and would be analogous to the utf8 string feature.

What is it you'd hope it would do it's not already doing? SharpLab

I thought the runtime materialized the string and created a span over it then, but it seems I was wrong despite the IL using ldstr.

[AlekseyTs]

Done with review pass (commit 2), new tests are not reviewed.

[AlekseyTs]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[AlekseyTs]

Done with review pass (commit 11)

[stephentoub]

Ok. Let's go without regression test for this scenario. Based on code review, the current behavior should be as expected.

Great, thanks.

[stephentoub]

Feedback addressed, thanks.

[AlekseyTs]

LGTM (commit 12)

[AlekseyTs]

@jcouv Please review the latest revision

[jcouv]

LGTM Thanks (iteration 12)

[jcouv]

Thanks @stephentoub :-)

[stephentoub]

Thank you, both, for the reviews.

[EgorBo]

Looking forward to seeing a huge PR against dotnet/runtime to replace all arrays with ROS<> for primitive types other than byte 😄

[stephentoub]

I have it ready to go, we just need the new compiler to flow in :)

[codemonkey85]

FYI, it looks like this change doesn't work in Blazor WebAssembly. I think it's an issue with Mono? I created a sample solution to show that it works in a Console app, and not in a Blazor WASM app: https://github.com/codemonkey85/BlazorWasmIssueWithArrayInitializationWithRelevantPrimitives