Description

NET 8:

NET 9 (or NET 8 with AVX512F_VL=0):

Reproduction Steps

It is terribly difficult to narrow down the issue.

There is a "massive" method at https://github.com/TechPizzaDev/SharpBlaze/blob/f330516bd8e88b607e36b6362e06b90f30472029/SharpBlaze/Linearizer.cs#L459. This method contains a lot of smaller inlined methods, and since most of the small methods are marked with AggressiveInlining, the massive ProcessUncontained method turns out to around 7kB of JIT ASM, and the JIT gives up on inlining at the end which causes helper methods of InlineArray to show up.
As soon as the JIT gives up on inlining (by tweaking MethodImplOptions in hot paths), the issues seemingly start to appear.

This project is a verbatim port of https://github.com/aurimasg/blaze to C#, and the 30k-Paris assets can be found at that original repo.

Expected behavior

Inlining and tiered compilation does not affect behavior. Release and debug builds create the same result.

Actual behavior

Tiered compilation changes the result (most likely because of inlining changing between JIT tiers).

Changing from [MethodImpl(MethodImplOptions.AggressiveInlining)] to [MethodImpl(MethodImplOptions.NoInlining)] reduces the problem in some hot paths (tiered compilation will sometimes stabilize to a correct result, but the result changing at all should not occur):
https://github.com/TechPizzaDev/SharpBlaze/blob/f330516bd8e88b607e36b6362e06b90f30472029/SharpBlaze/Linearizer.cs#L938-L940

Debug builds produce a correct result unlike Release builds.

Regression?

Since AVX512 plays a role, it seems unlikely that .NET 7 is affected (since AVX512 was only exposed in .NET 8).

Known Workarounds

Disable AVX512V_FL with DOTNET_EnableAVX512F_VL="0".

Updating to .NET 9 Preview does make the issues disappear, but looking at the disassembly it could simply be because .NET 9 has better inlining, which could hide the underlying issue.

Configuration

.NET: 8.0.3
OS: Microsoft Windows 11 Home (10.0.22631 version 22631)
CPU: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz
Arch: x64

Other information

I could not narrow the issue down to any specific instruction sequence, and the only obvious difference I could see from a glance between NET8 and NET9 was a few vbroadcasti32x4 instead of vmovups that look like the result of #92017 but this is unlikely the problem.

Here is a zip with some JIT disasm.