Vector256 assert is firing for crossgen'd SPCL

[AaronRobinsonMSFT]

See #89986 for short term fix. Reverted

From @tannergooding at #89986 (comment)

The general issue is that NarrowUtf16ToAscii was compiled under R2R and targeted V128. It hit 30 invocations, was rejitted, and now targets V256. However, NarrowToUtf16_Intrinsified_256 will now be hitting its first invocation. Since its not marked as compExactlyDependsOn it runs its R2R code and hits the assert.

In #89223 the following optimization flag was removed. Placing this back fixes this failure. However, there is likely some other underlying issue to investigate. See #90278 for revert of changes from #89223.

<CrossGenDllCmd>$(CrossGenDllCmd) -O</CrossGenDllCmd>

Immediate work around is to disable R2R: DOTNET_ReadyToRun=0

Example of stack

Vector256 is required.
   at System.Text.Ascii.NarrowUtf16ToAscii(Char* pUtf16Buffer, Byte* pAsciiBuffer, UIntPtr elementCount)
   at System.Text.Unicode.Utf8Utility.TranscodeToUtf8(Char* pInputBuffer, Int32 inputLength, Byte* pOutputBuffer, Int32 outputBytesRemaining, Char*& pInputBufferRemaining, Byte*& pOutputBufferRemaining)
   at System.Text.UTF8Encoding.GetBytes(String s, Int32 charIndex, Int32 charCount, Byte[] bytes, Int32 byteIndex)
   at System.Text.Encoding.GetBytes(String s)
   at System.Text.UTF8Encoding.UTF8EncodingSealed.GetBytes(String s)
   at System.Diagnostics.Tracing.ManifestBuilder.CreateManifest()
   at System.Diagnostics.Tracing.EventSource.CreateManifestAndDescriptors(Type eventSourceType, String eventSourceDllName, EventSource source, EventManifestOptions flags)
   at System.Diagnostics.Tracing.EventSource.EnsureDescriptorsInitialized()
   at System.Diagnostics.Tracing.EventSource.DoCommand(EventCommandEventArgs commandArgs)
   at System.Diagnostics.Tracing.EventSource.Initialize(Guid eventSourceGuid, String eventSourceName, String[] traits)
   at System.Diagnostics.Tracing.EventSource..ctor(Guid eventSourceGuid, String eventSourceName, EventSourceSettings settings, String[] traits)
   at System.Diagnostics.Tracing.EventSource..ctor(Guid eventSourceGuid, String eventSourceName)
   at System.Threading.Tasks.TplEventSource..ctor()
   at System.Threading.Tasks.TplEventSource..cctor()
   at System.Threading.Tasks.Task.ScheduleAndStart(Boolean needsProtection)
   at System.Threading.Tasks.Task.InternalStartNew(Task creatingTask, Delegate action, Object state, CancellationToken cancellationToken, TaskScheduler scheduler, TaskCreationOptions options, InternalTaskOptions internalOptions)

/cc @ivdiazsa @trylek

[AaronRobinsonMSFT]

/cc @mangod9

[ivdiazsa]

That optimization prevents the runtime from jumping to V256 immediately. Will send a PR restoring it, as well as the assert. Hopefully, it was just an unnecessary removal and the tests the original PR was supposed to fix remain fixed. If not, then we'll have a deeper problem in our hands to look at.

[ivdiazsa]

PR #90278 addressed this issue and things should work "normally" again. In other words, DOTNET_ReadyToRun can be enabled again without breaking or triggering asserts. However, a bigger underlying problem was exposed with this incident that we will have to solve at some point, so leaving this issue open to track that progress and not forget about it.

[ivdiazsa]

Is this still an issue? I tried reproducing it with just calling the main build script as mentioned here (#89986 (comment)), but to no avail. My builds all went fine, both with and without the Crossgen2 -O flag, which was what defined the behavior of triggering or not the assert.

[ivdiazsa]

Closing for now since it hasn't been reproducible anymore. Will reopen if it happens again.