Expose cross-platform helpers for Vector64, Vector128, and Vector256

[tannergooding]

This mostly resolves #49397 by exposes cross platform helpers for core functionality, mirroring Vector.

This PR is mostly the tests and the actual product changes are much much smaller than the sum. As with the other HWIntrinsic PRs, the tests are templated and are largely autogenerated from a small table. It is recommended to give a pass over a couple of the templates and the template input data, and not to try and review every test individually. There aren't any new concepts here, just cloning the existing templates with a few tweaks for the shared types.

In particular this PR is (numbers are slightly off now due to a few fixes, but largely still representative):

• +3171, -1226 for the JIT - Largely a refactoring to share SimdAsHWIntrinsic logic with the Vector64/128/256 code paths
• +7494, -3090 for the Libraries - Small refactoring + Software fallback logic for each API
• +1523, -0001 for the Test Metadata Table - Largely copy/pasted from our existing hwintrinsic scenarios
• +3856, -0000 for the Test Templates - Largely copy/pasted from our existing hwintrinsic scenarios
• The remaining 444,136 lines are the generated tests (roughly 10 tests per API exposed, covering all the scenarios we said were important and are covering for the existing HWIntrinsics)

This does not cover Narrow, Widen, ConverTo*, or IsHardwareAccelerated. These remaining APIs will go in a separate PR since it requires a bit more refactoring to make work (Vector<T> still implements these using the "legacy" SIMD support and the PR will need to update that to use SimdAsHWIntrinsic and to have the logic shareable with the Vector64/128/256<T> paths).

This will unblock some work on related issues as well as allow us to merge several code paths on the managed side where the core logic is the same between various platforms. The related issues that will be resolved following this PR include:

• Implementing Narrow, Widen, and ConvertTo
• Extend Vector64<T>, Vector128<T>, and Vector256<T> to support nint and nuint #52017 - Which will update Vector64/128/256 to support nint/nuint, bringing it inline with the support added for Vector this release. This is expected to be fairly small and should mostly just be removing a check
• Extend System.Runtime.Intrinsics.X86 to support nint and nuint #52021 and Extend System.Runtime.Intrinsics.Arm to support nint and nuint #52027 - Which will expose nint/nuint functionality for the actual intrinsics, this should likewise be decently small and should mostly be managed code after Extend Vector64<T>, Vector128<T>, and Vector256<T> to support nint and nuint #52017

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[tannergooding]

Going to run isa tests and make sure everything is passing before marking this as ready-for-review.

[tannergooding]

/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm, runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[tannergooding]

/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm, runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[tannergooding]

/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm, runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[tannergooding]

Just merged the workaround. Try rebasing again.

Thanks! Just did that, hopefully the AOT legs pass now

[echesakov]

Sorry for the delay.

Overall, the JIT changes look good. I left couple suggestions and one nit.

[echesakov]

I don't think this is the most optimal way of implementing Vector128.GetUpper()...

Perhaps, something that does DUP Vd, Vn.D[1] should be used instead.
This would correspond to vector.AsUInt64().GetElement(1).As<T>()

[tannergooding]

Do you mind if I fix this in a follow up PR (just so we can go ahead and get this one resolved and avoid further downstream conflicts)?

Also noting, this might be a case where we want to recognize the ExtractVector128 pattern and replace it with DUP if we know its always going to be more efficient...

[echesakov]

Sure, I meant to write that this work can wait when posted the message (but forgot).

[kunalspathak]

Need to double check if these arm64 improvements are related - dotnet/perf-autofiling-issues#1715

[jkotas]

This added close to 500,000 lines of auto-generated tests. Auto-generated tests like this are starting to kill us - in the repo footprint, build times and test times.

[tannergooding]

Auto-generated tests like this are starting to kill us - in the repo footprint, build times and test times.

@jkotas, We have several thousand APIs here, each of which need to have their basic functionality testing. Additionally, since they add a range of support to various phases of the JIT including new instructions and new encodings they need some validation that various operations, such as memory read/writes get folded into the instruction, CSE, etc work as expected.

Since we can't unit test phases of the JIT, we are stuck with functional tests written in C# that try to ensure trees are generated that cover the relevant patterns. If we could unit test phases, such as emit, we could have a much higher bar of confidence with many fewer tests, as we could directly validate based on the known encoding scenarios.

Many of these could likely be moved to some outerloop and only run on PRs known to be touching/impacting HWIntrinsic codegen (reducing the cost of your average PR/commit); but as is, these tests as is have caught a number of bugs and other issues that wouldn't have been exposed otherwise and so I don't think they should be removed from the repo until we have a suitable replacement.

[jkotas]

Some data:

src/tests before this PR: 488,952,913 bytes
src/tests after this PR: 509,473,324 bytes

This PR grew src/tests footprint by more than 4%.

src/tests is about 60% of the dotnet/runtime repo disk size footprint. Yes, src/tests sources are 1.5x more than sources for both runtimes, all libraries and all libraries tests combined.

I understand that we do not have better option currently, but we may need to have to create one if this continues to grow like this.

[tannergooding]

I understand that we do not have better option currently, but we may need to have to create one if this continues to grow like this.

I fully support having a better alternative here. I think the ideal scenario would be:

• Emitter is unit testable; we can actually write tests for scenarios like INS_addps xmm0, xmm0, INS_addps xmm0 xmm15, and INS_addps xmm0, [addr] directly
  • Such tests would be significantly cheaper to run and validate; the also give a higher bar of confidence with less work for core scenarios
• All of the existing src/tests/JIT/HardwareIntrinsics jobs are removed and replaced with Library tests that do basic functionality validation (e.g. ensure Sse.Add is behaving as expected and does per-element addition).

This would cover the majority of bugs and issues we've hit so far at a much cheaper cost. There would still be some things, like lowering, containment, and value numbering that wouldn't be covered here; but we've not hit any issues there that weren't immediately caught by general use of the intrinsics in the BCL.

[fanyang-mono]

This PR caused some regression for TE benchmarks when running with Mono. I've created an issue to track it #61484. @tannergooding Could you take a look?