[interp] Repair interp simd's ability to find certain operators; support vectors of char

[kg]

While inspecting the performance of some vectorized BCL code, I noticed that I accidentally mangled one of the binary search lists.
There also appear to be some cases where vectors of char are used, so I touched up the code to make sure that we will select the right intrinsic in that case if we already supported U2.

[ghost]

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

Issue Details

---

While inspecting the performance of some vectorized BCL code, I noticed that I accidentally mangled one of the binary search lists.
There also appear to be some cases where vectors of char are used, so I touched up the code to make sure that we will select the right intrinsic in that case if we already supported U2.

Author:	kg
Assignees:	-
Labels:	area-Codegen-Interpreter-mono
Milestone:	-

[kg]

The two browser-wasm windows lane failures appear to be some sort of AZDO git flake (fetch failed) that persisted even after I re-ran the lanes. Debugger failure is an unrelated chrome crash. One of the others is NuGet Migrations.

[tannergooding]

There also appear to be some cases where vectors of char are used

Can you point me to this code? Char is strictly unsupported and any of those paths should throw. We have one managed helper, that I’m aware of, which deals with ref char and returning a Vector###<ushort> but it’s not intended to be an intrinsic

[kg]

There also appear to be some cases where vectors of char are used

Can you point me to this code? Char is strictly unsupported and any of those paths should throw. We have one managed helper, that I’m aware of, which deals with ref char and returning a Vector###<ushort> but it’s not intended to be an intrinsic

I was digging into cases where intrinsics weren't being properly handled, and I saw a lot of stuff over <T> that appeared to support char. If char is officially not supported then I can remove that part from this in a future PR.

[tannergooding]

If char is officially not supported then I can remove that part from this in a future PR.

It's not. We only support the types that return IsSupported == true: https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Runtime/Intrinsics/Vector128_1.cs#L65-L84

Anything else should be throwing a NotSupportedException if a public API is called.

I saw a lot of stuff over that appeared to support char.

We have a lot of code that operates over a backing buffer of char, but the constructed Vector###<T> should always be a supported type (typically ushort).

If you find any code that isn't setup like this, then we probably have a bug that snuck in somewhere and that we should get patched.