JIT: assertion propagation truncates 64-bit constant during range inference

[AndyAyersMS]

Repro

using System;
using System.Runtime.CompilerServices;

public static class Program
{
    [MethodImpl(MethodImplOptions.NoInlining)]
    static ulong F(ulong p1)
    {
        int v6 = 0, v13 = 0, v21 = 0;
        ulong v2 = 0, v4 = 0, v5 = 0, v42 = 0;

    b0:
        v4 = 0 - p1;
        v6 = p1 == 0xFFFE008000000000UL ? 1 : 0;
        if (v6 != 0) goto b1;
        goto b4;
    b1:
        v13 = v4 != v2 ? 1 : 0;
        if (v13 != 0) goto b2;
        goto b5;
    b2:
        if (v21 != 0) goto b7;
        goto b6;
    b4:
        goto b0;
    b5:
        v42 = v5 % (ulong)(Environment.TickCount & 0);
        goto b1;
    b6:
        return 0;
    b7:
        return v42;
    }

    public static int Main()
    {
        Console.WriteLine($"{F(0xFFFE008000000000UL):X16}");
        return 0;
    }
}

MinOpts prints 0000000000000000. FullOpts instead enters b5 and throws DivideByZeroException. DOTNET_JitDoAssertionProp=0 avoids the failure.

Range inference consumes the 64-bit assertion p1 == 0xFFFE008000000000, truncates the constant to its low 32 bits (0), and incorrectly proves 0 - p1 == 0. Requiring the assertion constant to FitsIn<int> before using it to tighten an int32 Range fixes the repro.

[dotnet-policy-service]

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

[AndyAyersMS]

FYI @EgorBo, you've been working in range prop recently. Seems like a simple fix.