Remove Vector<T> fallbacks for Vector128<T>

[stephentoub]

I believe the only reason we were keeping these around were some mono platforms that accelerated Vector<T> but not Vector128<T>...

@fanyang-mono, @radekdoulik, are we able to remove these now?

[ghost]

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I believe the only reason we were keeping these around were some mono platforms that accelerated Vector<T> but not Vector128<T>...

@fanyang-mono, @radekdoulik, are we able to remove these now?

Author:	stephentoub
Assignees:	stephentoub
Labels:	area-System.Memory
Milestone:	-

[adamsitnik]

This PR warms my hart, I hope we can remove this code path ;)

[stephentoub]

@SamMonoRT, any insights here?

[fanyang-mono]

In .NET8, we worked on intrinsifying Vector128 for mini JIT on arm64, but we haven't do that for amd64. I would hold on doing this, until that work is finished.

[stephentoub]

Thanks. Do we have an ETA for appx when that will happen?

[radekdoulik]

On wasm this should be fine, the Vector128 coverage is pretty good. I can fill in if anything would regress.

[SamMonoRT]

In .NET8, we worked on intrinsifying Vector128 for mini JIT on arm64, but we haven't do that for amd64. I would hold on doing this, until that work is finished.

@fanyang-mono - We implemented a few Vector128 APIs on AMDx64 via our intern last year. Do we have a list of remaining ones ? -- Is this tracking issue accurate/updated - #66392 ?

@stephentoub - AMDx64 is low priority for us, but we will evaluate and consider implementing remaining ones (based on Fan's response) this summer. I wouldn't expect that to be completed prior to Preview 7 at this time.

[fanyang-mono]

The intern added support for Vector128 support with LLVM as backend for AMD64 last summer. We used the doc project file to track at that time. I will create an issue to clarify this, as what I remembered that most of the API's should be supported.

[fanyang-mono]

Thanks. Do we have an ETA for appx when that will happen?

I don't know atm, maybe in .NET9 time frame, but can't say for sure.

[stephentoub]

@fanyang-mono, are you saying then that it's important these Vector<T> code paths remain here for .NET 8? 😦

[fanyang-mono]

@fanyang-mono, are you saying then that it's important these Vector<T> code paths remain here for .NET 8? 😦

I just discussed this topic with my manager Sam, we understood the importance of this code change and are currently evaluating our options. Will keep you posted. The work is tracked by #86272

[stephentoub]

To be clear, we've lived with it for this long, we can live with it for a bit longer if necessary. It'd just be really nice to get rid of :-)

[stephentoub]

To at least make some progress here, I will ifdef these code paths to just be for mono for now rather than deleting them entirely. Then at least for coreclr and nativeaot it won't impact corelib binaries for .NET 8.

[stephentoub]

I've updated the PR to just ifdef the Vector<T> paths to be mono-specific instead of outright deleting them.
cc: @tannergooding

[stephentoub]

@SamMonoRT, this should be a nop for mono so I assume you're ok with it. We can delete the code paths and improve maintainability when mono is ready

@adamsitnik, @EgorBo, or @tannergooding, mind reviewing?

[SamMonoRT]

@fanyang-mono - need to make sure we track the cleanup of this file once the implementations are completed on our side.

[fanyang-mono]

@fanyang-mono - need to make sure we track the cleanup of this file once the implementations are completed on our side.

Updated #86272

[stephentoub]

Thanks, all