uint64 literals generate suboptimal IL code

[teo-tsirpanis]

Repro steps

Consider this function:

let inc x = x + 1UL

Now look at the generated IL code:

Expected behavior

IL_0000: ldarg.0
IL_0001: ldc.i4.1
IL_0002: conv.u8
IL_0003: add
IL_0004: ret

This is what C# generates. Generally, it should emit ldc.i4.#/ldc.i4.s/ldc.i4 with a conv, and only if the number is even bigger should it emit ldc.i8.

Actual behavior

IL_0000: ldarg.0
IL_0001: ldc.i8 1
IL_000a: add
IL_000b: ret

The function's IL code takes 12 bytes, instead of 5, as expected. This might interfere with the JIT's decision to inline small functions.

Known workarounds

let inc x = x + (uint64 1)

Related information

This happens only with uint64 literals. Literals of all other integral types (including signed int64) emit optimal code.

[cartermp]

JIT ASM for the F# and C# is identical on CoreCLR:

F#: https://sharplab.io/#v2:DYLgZgzgNALiCGEC2AfYBTGACAlgOwGMsAPLAXhKwGosBGAVQBkg

C#: https://sharplab.io/#v2:C4LghgzgtgPgAgJgIwFgBQcDMACR2DC2A3utmbjnEgGzYCuANgPYB2A5tgJIsDGAFI1YcAHgEpipclLgB2bMOwBqbEgDcUqZLIBfdNqA

But it may not be true for desktop .NET.

[teo-tsirpanis]

I know about the JITted code being identical. The problem is that F#'s IL code is not as compact as it is with C#. And as I said before, it might affect how the JIT performs inlining.

[cartermp]

Compactness of IL isn't necessarily a problem, which is also why optimization is difficult here. If the JIT optimizes it all the same, we'd need some evidence that this affects JIT inlining to say it's really a problem. As it stands, I think the best rationale for making a change here is consistency with C#.

[teo-tsirpanis]

I agree. What source files are responsible for that? I want to try to fix it myself.

[cartermp]

Awesome! A good place to start would probably be in ILXGen, perhaps here: https://github.com/dotnet/fsharp/blob/master/src/fsharp/IlxGen.fs#L2433

Typically ILXGen is where the "translate F# to IL" happens, though some lower-level stuff can occur elsewhere.