[API Proposal]: SVE AddRotateComplex should use an enum

[a74nh]

Background and motivation

Based on the discussion here

API Proposal

TODO: This possibly needs updating to take into account other APIs which use 0/90/180/270

namespace System.Runtime.Intrinsics.Arm

/// VectorT Summary
public abstract class Sve : AdvSimd
{
    
  /// T: float, double
  public static unsafe Vector<T> AddRotateComplex(Vector<T> op1, Vector<T> op2, enum SveRotationType rotation); 

// All possible prefetch types
  enum SveRotationType
  {
    rotate_90 = 0,   // Temporal fetch the addressed location for reading, to L1 cache.
    rotate_270 = 1,   // Streaming fetch the addressed location for reading, to L1 cache.
  };
}

API Usage

Alternative Designs

No response

Risks

No response

[dotnet-policy-service]

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

[a74nh]

In addition, this API is currently implemented as:
public static unsafe Vector<T> AddRotateComplex(Vector<T> left, Vector<T> right, [ConstantExpected(Min = 0, Max = (byte)(1))] byte rotation)

whereas the reviewed API does not have the ConstantExpected part:
public static unsafe Vector<T> AddRotateComplex(Vector<T> op1, Vector<T> op2, ulong imm_rotation);

[tannergooding]

Exposing enums is not always feasible and there would be dozens to hundreds of one off enums for cases like these.

For example, the SveRotationType proposed above isn't technically "sufficient", it is only one of the rotation enums and it happens to be specific to AddRotateComplex (FCADD). You also for FCMLA have:

rot = 0b00; // 0
rot = 0b01; // 90
rot = 0b10; // 180
rot = 0b11; // 270

So we would need to come up with "unique" names to represent these two rotation enums and consider how they impact any future instructions (for example, they also get used for CADD, CMLA, and potentially other scenarios) that may also need their own enums.

This ends up being fairly messy and is why we have historically kept it as simply byte control that directly represents the bits that are encoded into the instruction stream. The hardware instruction manuals and/or documentation covers how those bits are encoded and therefore how the values are interpreted.

Likewise the [ConstantExpected] has historically not been explicit in the review, it's simply an annotation that helps ensure users pass in values that will result in success rather than failure. The actual signature isn't changing at all, it's just making it clear that [0, 1] is the valid range and [2, 255] will result in a failure.

[a74nh]

I'm closing this as it's fairly unlikely to happen given the different rotation types across SVE.