Assertion failed 'tree->IsUnusedValue()' in 'Program:M0()' during 'Linear scan register alloc'

[BruceForstall]

This is an assertion on windows-x86 found with Fuzzlyn, e.g.,

https://dev.azure.com/dnceng-public/public/_build/results?buildId=1030675&view=ms.vss-build-web.run-extensions-tab

The Fuzzlyn reducer hasn't been able to reduce it, and the full test case is too large to include here.

Per the Fuzzlyn CI results:

Affected seeds:

16314885044184615716-vectort,vector128,vector256,x86aes,x86avx,x86avx2,x86avx512bw,x86avx512bwvl,x86avx512cd,x86avx512cdvl,x86avx512dq,x86avx512dqvl,x86avx512f,x86avx512fvl,x86bmi1,x86bmi2,x86fma,x86lzcnt,x86pclmulqdq,x86popcnt,x86sse,x86sse2,x86sse3,x86sse41,x86sse42,x86ssse3,x86x86base
8566430060631923646-vectort,vector128,vector256,x86aes,x86avx,x86avx2,x86avx512bw,x86avx512bwvl,x86avx512cd,x86avx512cdvl,x86avx512dq,x86avx512dqvl,x86avx512f,x86avx512fvl,x86bmi1,x86bmi2,x86fma,x86lzcnt,x86pclmulqdq,x86popcnt,x86sse,x86sse2,x86sse3,x86sse41,x86sse42,x86ssse3,x86x86base

Locally, I've verified a repro for:

// Generated by Fuzzlyn v2.9 on 2025-04-30 00:05:53
// Run on X64 Windows
// Seed: 4814653748228545744-vectort,vector128,vector256,x86aes,x86avx,x86avx2,x86avx512bw,x86avx512bwvl,x86avx512cd,x86avx512cdvl,x86avx512dq,x86avx512dqvl,x86avx512f,x86avx512fvl,x86bmi1,x86bmi2,x86fma,x86lzcnt,x86pclmulqdq,x86popcnt,x86sse,x86sse2,x86sse3,x86sse41,x86sse42,x86ssse3,x86x86base
...

@dotnet/jit-contrib

[dotnet-policy-service]

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

[kunalspathak]

In case it is easy, can you attach superpmi collection for the test case?

[BruceForstall]

Ok, I was able to manually construct a small repro after examining the JitDump and determining the giant parts of the source code probably didn't matter.

// Generated by Fuzzlyn v2.9 on 2025-04-30 00:05:53
// Run on X64 Windows
// Seed: 4814653748228545744-vectort,vector128,vector256,x86aes,x86avx,x86avx2,x86avx512bw,x86avx512bwvl,x86avx512cd,x86avx512cdvl,x86avx512dq,x86avx512dqvl,x86avx512f,x86avx512fvl,x86bmi1,x86bmi2,x86fma,x86lzcnt,x86pclmulqdq,x86popcnt,x86sse,x86sse2,x86sse3,x86sse41,x86sse42,x86ssse3,x86x86base
using System;
using System.Numerics;
using System.Runtime.Intrinsics;
using System.Runtime.Intrinsics.X86;

namespace NS
{
public class ProblemClass
{
    static public int var6 = -7;
    public static int Main()
    {
        if (Sse41.TestC((Vector128<long>)Sse42.CompareGreaterThan((Vector128<long>)Avx2.BroadcastScalarToVector128((Vector128<long>)Vector128.Create<long>((long)-2L)), (Vector128<long>)Vector128.Create((long)-9223372036854775807L, (long)-9223372036854775807L)), (Vector128<long>)Vector128.CreateScalar((long)6896620476846143516L)))
        {
            var6 = var6 + 7;
        }
        return var6;
    }
}
}

[kunalspathak]

I am not able to repro this on avx512 and non-avx512 windows/x86 on 3104b88. In case it still repros for you, feel free to reopen and share the superpmi collection for it.

[jakobbotsch]

It still fails in every Fuzzlyn run.

[kunalspathak]

It still fails in every Fuzzlyn run.

do you mind sharing the spmi collection?

[jakobbotsch]

Attached collection from a recent Fuzzlyn run (they are automatically uploaded as artifacts)

Repros for me on bb48410

repro-6028.zip

[kunalspathak]

               [038143] -----------                t38143 =    LCL_FLD   int    V1485 tmp1445    [+0]
               [038144] -----------                t38144 =    LCL_FLD   int    V1485 tmp1445    [+4]
                                                            ┌──▌  t38143 int    
                                                            ├──▌  t38144 int    
               [038145] -----------                t38145 = ▌  LONG      long  
                                                            ┌──▌  t38145 long   
N027 (???,???) [016565] -ACXG+-----                t16565 = ▌  HWINTRINSIC simd32 32 int BroadcastScalarToVector256

@saucecontrol - The node [038145] should be marked as contained it looks like, but is not. As a result, in lsra, when creating interval, we expect this node to be unused, but it is not. Is there some bug in marking such nodes as contained?

[saucecontrol]

That's a strange one. Broadcast codegen doesn't handle decomposed longs, so it wouldn't be right to just mark the GT_LONG contained. It really needs its own codegen, so there should be a CreateScalarUnsafe between the broadcast and the GT_LONG. I can't think of a way offhand we could end up with this IR.

Since this is coming from my changes, I'm happy to take it over over if you like.

[kunalspathak]

Since this is coming from my changes, I'm happy to take it over over if you like.

Assigning to you @saucecontrol

[saucecontrol]

Fix is up in #116002