Enable multi-register intrinsics support for Arm64

[echesakov]

Overview

We achieved parity with x64 for Arm64 intrinsics support in .NET 5 for most of them except for multi-register intrinsics. We need more work to enable multi-register intrinsics for Arm64. The work is integral in that it involves changes in JIT, libraries and mono to enable working intrinsics.

Work Items

• Enable multi-register intrinsics in the JIT
  • [Arm64] LoadPairVector64 and LoadPairVector128 #39243
  • Couple optimization to MultiRegStoreLoc #64857
  • (WIP) Remove condition that forbids promotion of HFAs with CUSTOMLAYOUT flag #64863
  • Follow up and enable usage of LoadPairVector64/128 in the libraries (see comment)
  • (Intel) Bmi2.MultiplyNoFlags issues #11782 (in plan)
  • Address Copy/paste error in GenTree::GetRegSpillFlagByIdx for xarch hwintrinsics #52473 (in plan)
  • Support register allocation for intrinsics returning value in a sequence of registers (e.g. V0-V2 (note that this is different from the LoadPairVector64/128 which returns result in two independent SIMD registers). [LSRA] Add support for allocating consecutive registers #39457. Implemented in Arm64: Implement VectorTableLookup/VectorTableLookupExtension intrinsinsic + Consecutive registers support #80297.
  • Propose and approve multi-register intrinsics LoadVector and StoreVector APIs on Arm64 ([API Proposal]: Arm64 [Load/Store]Vector64 and [Load/Store]Vector128 for 2,3 and 4 variants #84510)
  • (Q2'23) Implement multi-register intrinsics LoadVector and StoreVector APIs on Arm64 (such as ones that will expose LD[1-4],ST[1-4] instructions)
  • Implement multi-register intrinsics on Arm64 (such as ones that will expose TBL,TBX instructions)

Follow-up (after the JIT work is completed)

• Libraries support to use the new intrinsics
• monoVM support on the new intrinsics.

Benchmarks to use

• Microbenchmarks (for the libraries methods that will be intrinsified with the new intrinsics)

category:cq
theme:register-allocator
skill-level:expert
cost:medium
impact:medium

[ghost]

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

Issue Details

---

Overview

We achieved parity with x64 for Arm64 intrinsics support in .NET 5 for most of them except for multi-register intrinsics. We need more work to enable multi-register intrinsics for Arm64. The work is integral in that it involves changes in JIT, libraries and mono to enable working intrinsics.

Work Items

• Enable multi-register intrinsics in the JIT
  • [Arm64] LoadPairVector64 and LoadPairVector128 #39243
  • Support register allocation for intrinsics returning value in a sequence of registers (e.g. V0-V2 (note that this what different from the LoadPairVector64/128 which returns result in two independent SIMD registers).
  • Propose and approve multi-register intrinsics APIs on Arm64 (these are expected to "look" similar to LoadPairVector/StorePairVector - i.e. using a ValueTuple of Vector values to express multi-register values)
  • Implement multi-register intrinsics on Arm64 (such as ones that will expose LD[1-4],ST[1-4],TBL,'TBX` instructions)

Follow-up (after the JIT work is completed)

• Libraries support to use the new intrinsics
• monoVM support on the new intrinsics.

Benchmarks to use

• Microbenchmarks (for the libraries methods that will be intinsified with the new intrinsics)

Author:	echesakovMSFT
Assignees:	-
Labels:	arch-arm64, area-CodeGen-coreclr, User Story
Milestone:	-

[EgorBo]

will it fix div on x64 returning result and mod in two registers? 🙂

[echesakov]

will it fix div on x64 returning result and mod in two registers? 🙂

Not this work item, which I tend to think of as "LSRA allocating spans of registers" work.

However #64864 should lay foundation for DivRem (or MultiplyNoFlags2) intrinsics that returns pairs of values. #64857 is another relevant piece and needed to avoid unnecessary mov-s with multireg intrinsics.

[huoyaoyuan]

In #66551, I've actually made multi-reg DivRem on x64 works. @EgorBo you can check if there are works remaining.

[JulieLeeMSFT]

Moved to .NET 8.

[kunalspathak]

We will continue working on #84510 in .NET 9.

[kunalspathak]

This is completed.