JIT: Bad codegen with ulong -> float conversion on arm64

[jakobbotsch]

// Generated by Fuzzlyn v2.2 on 2024-08-13 00:04:04
// Run on Arm64 MacOS
// Seed: 13207615092246842583-vectort,vector64,vector128,armadvsimd,armadvsimdarm64,armaes,armarmbase,armarmbasearm64,armcrc32,armcrc32arm64,armdp,armrdm,armrdmarm64,armsha1,armsha256
// Reduced from 226.8 KiB to 0.4 KiB in 00:02:12
// Debug: Outputs 1600094603
// Release: Outputs 1600094604
using System;
using System.Runtime.CompilerServices;
using System.Numerics;
using System.Runtime.Intrinsics;
using System.Runtime.Intrinsics.Arm;

public class Program
{
    public static void Main()
    {
        ulong vr10 = 16105307123914158031UL;
        float vr11 = 4294967295U | vr10;
        System.Console.WriteLine(System.BitConverter.SingleToUInt32Bits(vr11));
    }
}

cc @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.

[amanasifkhalid]

Sounds like the constant folding behavior doesn't match the normal path. I can take this.

[amanasifkhalid]

Here's the relevant bit of Debug codegen:

movz    x0, #0xAFCF
movk    x0, #0xE778 LSL #16
movk    x0, #0x8B7F LSL #32
movk    x0, #0xDF81 LSL #48
str     x0, [fp, #0x18]     // [V00 loc0]
movn    w0, #0
mov     w0, w0
ldr     x1, [fp, #0x18]     // [V00 loc0]
orr     x0, x0, x1
ucvtf   s16, x0
str     s16, [fp, #0x14]    // [V01 loc1]
ldr     s0, [fp, #0x14]     // [V01 loc1]

Since we don't const-fold anything away, we use ucvtf to cast the result of the bitwise-OR to a float. ARM64's cast instructions have encodings specifically for narrowing scenarios, so there's no need to first cast the OR result to a double, and then to a float. In Release, the const-folding logic in FloatingPointUtils::convertUInt64ToFloat does not reflect this behavior; it first casts to double, and then to float. This seems to have subtle differences in rounding behavior, hence the Debug/Release diffs.

Updating FloatingPointUtils::convertUInt64ToFloat to cast directly to float on ARM64 fixes this diff, though it's worth noting we'll get subtle differences in const folding for casts for AltJit scenarios because of this (though this already seemed to be the case -- on x64, the output of the repro is 1600094604 in Debug and Release). I'm guessing we're ok with these diffs? I'm not sure we can model these casts in a platform-agnostic way.