Make Vector64<T>, Vector128<T>, and Vector256<T> work with the debugger.

[tannergooding]

Rationale

Currently Vector64<T>, Vector128<T> and Vector256<T> in the System.Runtime.Intrinsics namespace are opaque types.

This is great for the hardware intrinsics API, but it provides a very poor experience in the debugger.

As such, I propose that the types be extended with the DebuggerTypeProxy and DebuggerDisplay attributes to provide a better debugging experience.

Additional Thoughts

I propose the DebuggerDisplay attribute should display a string of T elements.

Ex: For Vector128<float>, it would display "{e0, e1, e2, e3}", for Vector128<ushort> it would display "{e0, e1, e2, e3, e4, e5, e6, e7}" (where e# is the value of that given element).

I propose DebuggerTypeProxy should have several properties in the form of public <type>[] <type>View and there should be a property for each supported value of T (i.e. float, double, byte, short, int, long, sbyte, ushort, uint, and ulong).

Ex: Vector128DebugView would have public byte[] ByteView {get;}, public float[] SingleView {get;}, etc...

Notes

In doing a prototype for this proposal, I found that the debugger would always see 0 as the value of the underlying struct. I initially attempted to add serialization support, but that did not resolve the issue.

However, adding private fields to the structs allowed it to work (I'm guessing the debugger is marshalling the type, or something similar).

Ex: I had to change Vector128<T> to the following in order for DebuggerTypeProxy and DebuggerDisplay to work:

[Intrinsic]
[StructLayout(LayoutKind.Sequential, Size = 16)]
[DebuggerTypeProxy(typeof(Vector128DebugView<>))]
[DebuggerDisplay("{DebuggerDisplay,nq}")]
public struct Vector128<T> where T : struct
{
    // These fields exist purely so debug view works
    private ulong _lower;
    private ulong _upper;
}

[tannergooding]

FYI. @fiigii, @CarolEidt, @eerhardt, @RussKeldorph

[fiigii]

Why do we need the fields _lower and _upper? Shall we expose a ToString method for debugging (not only work with the debugger)?

[tannergooding]

Why do we need the fields _lower and _upper?

As mentioned, I was prototyping this and couldn't get it to work without explicitly adding private fields that equaled 16-bytes. I did try to make the type serializable first, so I am guessing the debugger is doing marshalling or something else instead. There might be some other way of getting it to work (custom marshaller maybe), but I wouldn't know off the top of my head.

Shall we expose a ToString method for debugging (not only work with the debugger)?

You mean for Console.WriteLine and the like? That would work as well, but I think would need to be an explicit design decision to implement that support for the type, since it is farther reaching and may impact other areas.

[tannergooding]

Also CC. @sdmaclea, since it would impact these types for ARM/ARM64

If there are 10 properties, one property for each supported primitive type, then that means the user would have to expand the variable, then figure out which one of the 10 arrays is correct, and expand it. The debugger could of course be updated to only show the correct property but that will require updates to all debuggers.

If showing the other arrays isn't important, then it only needs one public property that returns a System.Array.

[tannergooding]

If there are 10 properties, one property for each supported primitive type, then that means the user would have to expand the variable, then figure out which one of the 10 arrays is correct, and expand it.

@0xd4d, The debugger will already display which type the field is:

The other properties provide a way to view the data in the other valid formats (which is sometimes important or useful):

Both of these are very similar to the way __m128 works in the native compiler:

[4creators]

IMO it is best to avoid blowing up the types and at maximum have System.Array property (not desirable) or have a conversion operator in Vector128DebugView which would convert VectorNNN to struct<T>/class<T> which would be easy to visualize. This would create the right distance for separation of concerns.

[eerhardt]

cc @mikem8361 - in case he has any insight into why _lower and _upper are necessary.

[jkotas]

Would one dummy field of type T work?

[tannergooding]

Would one dummy field of type T work?

No, then only sizeof(T) bits were accessible in the debugher

[tannergooding]

have a conversion operator in Vector128DebugView

The Debug View types are generally internal. Additionally, they debugger does not expose the proxy types directly, so there is no way to make use of operators on a proxy type (or anything other than public properties/fields really).

The primary goal should be to make Vector128 and Vector256 work with the debugger, without causing the types to lose their opaqueness (ideally without having to modify the types beyond adding the appropriate attributes). Taking advantage of the debugger attributes to create proxy types (displayed on hover) and display strings (displayed in the locals/watch/ee) should work for this.

The one side effect, currently, is that adding the private fields (directly in the types, so marshalling works) makes those fields viewable in the locals/watch window under "view raw structures" mode.

[jkotas]

"view raw structures" mode

Ok, make sense. Would it be better to have the dummy fields as byte to better match what the type is?

[jkotas]

Linking related bug: https://github.com/dotnet/coreclr/issues/10148

[tannergooding]

Ok, make sense. Would it be better to have the dummy fields as byte to better match what the type is?

It might. I had done ulong for Vector128 and two Vector128 for Vector256 since that required adding less fields and "view raw structures" is generally a more advanced scenario.

I assume they would be something like private byte _0, _1, _2, ...; rather than _upper, _lower.

Linking related bug: #7626

I'm guessing there is either a marshalling or debugger bug when working with explicitly sized types. I know on the debugger side of things there are other scenarios that don't work well either (such as fixed sized buffers).

[tannergooding]

Looks like its probably in the debugger. Marshalling, serialization, and remoting (in other scenarios) seems to be working as expected