[Improvement] Optimize away boxing in some expression involving `as` operator, nullable value types, and type parameters

[VladimirReshetnikov]

using System;
using System.Runtime.CompilerServices;

readonly struct Container<T>
{
    private readonly T value;
    public Container(T value) => this.value = value;

    [MethodImpl(MethodImplOptions.AggressiveOptimization)]
    public TOther GetValueOrDefault<TOther>() where TOther : struct =>
        (value as TOther?).GetValueOrDefault(); // boxing occurs here
}

static class Program
{
    static void Main()
    {
        var container = new Container<Guid>(Guid.Empty);
        var count = 0;
        while (true)
        {
            // call a method where boxing may occur
            if (container.GetValueOrDefault<Guid>() != default)
                Console.WriteLine("...");

            // monitor GC events due to boxing
            var newCount = GC.CollectionCount(0);
            if (newCount != count)
                Console.WriteLine(count = newCount);
        }
    }
}

Expression (value as TOther?).GetValueOrDefault() in Container<T>.GetValueOrDefault can be considered as a simplified form of value is TOther ? (TOther) (object) value : default(TOther). Because JIT eliminates boxing in the latter form (when compiled in Release mode and started without debugger), it would be great if it could eliminate boxing in the former as well.

---

$env:ProgramFiles\dotnet\shared\Microsoft.NETCore.App\5.0.0-alpha.1.19564.1\.version

c77948d92a2f950140f09384f057cb893ec3955a
5.0.0-alpha.1.19564.1

category:cq
theme:boxing
skill-level:expert
cost:medium

[EgorBo]

As far as I understand JIT should eliminate such patterns:

box [nullable`1]
isinst valuetype
unbox.any valuetype 

and also for is:

box [nullable`1]
isinst valuetype
ldnull
cgt.un

[EgorBo]

I've made a prototype PR for RyuJIT https://github.com/EgorBo/runtime/commit/3e2c5ad9fa40867dd8919c156f1f3bf9ddeb5e7a

but the jit-diff tools didn't find such patterns in the BCL.
A test:

public static class MyClass
{
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    static int? Case1<T>(T value) => value as int?;

    static int? Test1() => Case1<int>(42);   // return new Nullable<int>(42);
    static int? Test2() => Case1<int?>(42);  // return new Nullable<int>(42);
    static int? Test3() => Case1<long>(42);  // return new Nullable<int>();
    static int? Test4() => Case1<long?>(42); // return new Nullable<int>();



    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    static bool Case2<T>(T value) => value is int?;

    static bool Test5() => Case2<int>(42);   // return true;
    static bool Test6() => Case2<int?>(42);  // return true;
    static bool Test7() => Case2<long>(42);  // return false;
    static bool Test8() => Case2<long?>(42); // return false;
}

Currently, RyuJIT emits boxing for all test cases: sharplab

[4creators]

but the jit-diff tools didn't find such patterns in the BCL.

IMHO it is irrelevant when determining if optimization works and equally not as relevant for determining if such patterns would be used in the production code. BCL is a special case of the .NET Core usage and not the best representative of real-world applications.

[AndyAyersMS]

@EgorBo the link to your prototype is not working.

I recall looking at box opts for nullables and backing away for some reason. Will have to go look again someday to remember why.

BCL is a special case of the .NET Core usage and not the best representative of real-world applications.

@4creators if you have suggestions as to what would be more representative, I'd love to hear them.