[.NET 7]Integer auto-vectorization bug

[koszeggy]

Description

The detailed description is here.

Summary: On some platforms uint/int vector initialization is wrong from ushort fields or arrays. Vector<T> and Vector128<T> are affected for sure, maybe others as well.

Reproduction Steps

using System;
using System.Numerics;
using System.Runtime.Intrinsics;

(ushort A, ushort R, ushort G, ushort B) c = (32768, 65535, 32768, 16384);

Vector128<uint> v1 = Vector128.Create(c.R, c.G, c.B, 0u);
Console.WriteLine(v1);
v1 = v1 * c.A / Vector128.Create(0xFFFFu);
Console.WriteLine(v1);

Span<uint> span = stackalloc uint[Vector<uint>.Count];
span[0] = c.R;
span[1] = c.G;
span[2] = c.B;
Vector<uint> v2 = new Vector<uint>(span) * c.A / new Vector<uint>(0xFFFF);
Console.WriteLine(v2);

Console.WriteLine();
Console.WriteLine(Vector128.Create((int)c.A));
Console.WriteLine(Vector128.Create((int)32768));
Console.WriteLine(Vector128.Create((int)c.A, (int)c.A, (int)c.A, (int)c.A));

Please note that the results are correct in SharpLab Release mode but are incorrect in Debug mode.

Expected behavior

The expected output (works in SharpLab Release mode):

<65535, 32768, 16384, 0>
<32768, 16384, 8192, 0>
<32768, 16384, 8192, 0, 0, 0, 0, 0>

<32768, 32768, 32768, 32768>
<32768, 32768, 32768, 32768>
<32768, 32768, 32768, 32768>

Actual behavior

Incorrect output (eg. in SharpLab Debug mode, .NET Fiddle or on my computer both in Release and Debug builds):

<65535, 32768, 16384, 0>
<32769, 49152, 57344, 0>
<32769, 49152, 57344, 0, 0, 0, 0, 0>

<-32768, -32768, -32768, -32768>
<32768, 32768, 32768, 32768>
<32768, 32768, 32768, 32768>

Regression?

In .NET Fiddle the .NET 6 platform appears to be working; however, some of the used overloaded operators were not available in .NET 6 so I'm not sure what it actually executes.

Known Workarounds

Vanilla operations, explicit usage of HW intrinsics, copying the ushort field into an uint first.

Configuration

.NET 7.0.200
Intel i5-8300H
Windows 11 (Version 10.0.22621.1265)

Other information

No response

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

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

Issue Details

---

Description

The detailed description is here.

Summary: On some platforms uint/int vector initialization is wrong from ushort fields or arrays. Vector<T> and Vector128<T> are affected for sure, maybe others as well.

Reproduction Steps

using System;
using System.Numerics;
using System.Runtime.Intrinsics;

(ushort A, ushort R, ushort G, ushort B) c = (32768, 65535, 32768, 16384);

Vector128<uint> v1 = Vector128.Create(c.R, c.G, c.B, 0u);
Console.WriteLine(v1);
v1 = v1 * c.A / Vector128.Create(0xFFFFu);
Console.WriteLine(v1);

Span<uint> span = stackalloc uint[Vector<uint>.Count];
span[0] = c.R;
span[1] = c.G;
span[2] = c.B;
Vector<uint> v2 = new Vector<uint>(span) * c.A / new Vector<uint>(0xFFFF);
Console.WriteLine(v2);

Console.WriteLine();
Console.WriteLine(Vector128.Create((int)c.A));
Console.WriteLine(Vector128.Create((int)32768));
Console.WriteLine(Vector128.Create((int)c.A, (int)c.A, (int)c.A, (int)c.A));

Please note that the results are correct in SharpLab Release mode but are incorrect in Debug mode.

Expected behavior

The expected output (works in SharpLab Release mode):

<65535, 32768, 16384, 0>
<32768, 16384, 8192, 0>
<32768, 16384, 8192, 0, 0, 0, 0, 0>

<32768, 32768, 32768, 32768>
<32768, 32768, 32768, 32768>
<32768, 32768, 32768, 32768>

Actual behavior

Incorrect output (eg. in SharpLab Debug mode, .NET Fiddle or on my computer both in Release and Debug builds):

<65535, 32768, 16384, 0>
<32769, 49152, 57344, 0>
<32769, 49152, 57344, 0, 0, 0, 0, 0>

<-32768, -32768, -32768, -32768>
<32768, 32768, 32768, 32768>
<32768, 32768, 32768, 32768>

Regression?

In .NET Fiddle the .NET 6 platform appears to be working; however, some of the used overloaded operators were not available in .NET 6 so I'm not sure what it actually executes.

Known Workarounds

Vanilla operations, explicit usage of HW intrinsics, copying the ushort field into an uint first.

Configuration

.NET 7.0.200
Intel i5-8300H
Windows 11 (Version 10.0.22621.1265)

Other information

No response

Author:	koszeggy
Assignees:	-
Labels:	area-System.Numerics, untriaged
Milestone:	-

[ghost]

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

Issue Details

---

Description

The detailed description is here.

Summary: On some platforms uint/int vector initialization is wrong from ushort fields or arrays. Vector<T> and Vector128<T> are affected for sure, maybe others as well.

Reproduction Steps

using System;
using System.Numerics;
using System.Runtime.Intrinsics;

(ushort A, ushort R, ushort G, ushort B) c = (32768, 65535, 32768, 16384);

Vector128<uint> v1 = Vector128.Create(c.R, c.G, c.B, 0u);
Console.WriteLine(v1);
v1 = v1 * c.A / Vector128.Create(0xFFFFu);
Console.WriteLine(v1);

Span<uint> span = stackalloc uint[Vector<uint>.Count];
span[0] = c.R;
span[1] = c.G;
span[2] = c.B;
Vector<uint> v2 = new Vector<uint>(span) * c.A / new Vector<uint>(0xFFFF);
Console.WriteLine(v2);

Console.WriteLine();
Console.WriteLine(Vector128.Create((int)c.A));
Console.WriteLine(Vector128.Create((int)32768));
Console.WriteLine(Vector128.Create((int)c.A, (int)c.A, (int)c.A, (int)c.A));

Please note that the results are correct in SharpLab Release mode but are incorrect in Debug mode.

Expected behavior

The expected output (works in SharpLab Release mode):

<65535, 32768, 16384, 0>
<32768, 16384, 8192, 0>
<32768, 16384, 8192, 0, 0, 0, 0, 0>

<32768, 32768, 32768, 32768>
<32768, 32768, 32768, 32768>
<32768, 32768, 32768, 32768>

Actual behavior

Incorrect output (eg. in SharpLab Debug mode, .NET Fiddle or on my computer both in Release and Debug builds):

<65535, 32768, 16384, 0>
<32769, 49152, 57344, 0>
<32769, 49152, 57344, 0, 0, 0, 0, 0>

<-32768, -32768, -32768, -32768>
<32768, 32768, 32768, 32768>
<32768, 32768, 32768, 32768>

Regression?

In .NET Fiddle the .NET 6 platform appears to be working; however, some of the used overloaded operators were not available in .NET 6 so I'm not sure what it actually executes.

Known Workarounds

Vanilla operations, explicit usage of HW intrinsics, copying the ushort field into an uint first.

Configuration

.NET 7.0.200
Intel i5-8300H
Windows 11 (Version 10.0.22621.1265)

Other information

No response

Author:	koszeggy
Assignees:	-
Labels:	bug, area-CodeGen-coreclr, untriaged
Milestone:	-

[EgorBo]

Seems like a small-type related bug in HW intrinsics import (with opts)

[EgorBo]

the problematic tree is:

└──▌  HWINTRINSIC simd16 uint Create
   └──▌  LCL_FLD   ushort(AX) V00 loc0

it ends up as a broadcast that loads more than ushort data

[EgorBo]

cc @tannergooding - presumably it needs GT_CAST here

[EgorBo]

Minimal repro:

class Prog
{
    [MethodImpl(MethodImplOptions.NoOptimization)]
    static void Main()
    {
        (ushort A, ushort R) c = (1, 65535);
        Vector128<uint> v1 = Vector128.Create((uint)2);
        v1 = v1 * c.A;
        Console.WriteLine(v1.ToScalar());
    }
}

[tannergooding]

We discussed it a bit in discord with @jakobbotsch as well and this shouldn't need a cast.

Rather there is likely something in codegen that is checking the wrong size when considering the containment opportunities.

[BruceForstall]

@jakobbotsch Can you take a look at this? In particular, do we need it fixed for .NET 8?

[jakobbotsch]

@jakobbotsch Can you take a look at this? In particular, do we need it fixed for .NET 8?

Yes, I think we should fix this for .NET 8 given that it is customer reported and results in silent bad codegen.