Ability to invoke interface method on generic struct without boxing

[stephentoub]

Related to:
dotnet/csharplang#905
https://github.com/dotnet/coreclr/issues/12877

In a method like:

public void Foo<T>(T t)
{
    ...
}

I want to be able to do the equivalent of:

if (t is ISomeInterface)
{
    ((ISomeInterface)t).InterfaceMethod();
}

but without incurring the associated boxing. I can work around https://github.com/dotnet/coreclr/issues/12877 with a hack like dotnet/coreclr@9a06301#diff-bc8ce62cfb625ddcc19d1f21b5c8b5c1R457, but that only addresses the is check; I'm not aware of any way currently to do the invocation without an allocation.

Example where this would be valuable:
dotnet/coreclr@9a06301#diff-bc8ce62cfb625ddcc19d1f21b5c8b5c1R427
Right now for this optimization in async methods, we have no way to special-case all ValueTask<T>s, instead having to special-case just those ValueTask<T>s for Ts we list here explicitly. If we had the ability to do the above pattern, we could make ValueTask<T> implement an internal interface that provided a Task AsTask() method that would let us fish out and use the underlying Task, which enable us to apply the optimization for all ValueTask<T>, regardless of the T.

[mburbea]

Yeah the only pattern that I know that works for that is similar to what is in ComparerHelpers which has probably non-devirtualizable use of generics and requires writing that awful pattern and allocates.

If static delegates or there was sort of unsafe helper around calli, you could jerry-rig it by creating a static factory for the signature.

[AndyAyersMS]

I have a prototype of this in the works, see master...AndyAyersMS:DevirtUnboxStub. It should be able to remove the box but will still need to make a local copy of the value class, since the jit does not know if the target method will modify the value class or not.

Even when the target method is then inlined and clearly does not modify the value class, the jit will likely not be able to optimize away the copy.

But boxing makes a copy too, so overall the impact should be that a heap allocation turns into a stack allocation and the call is potentially inlined (and avoids the unboxing stub).

If this seems like a reasonable improvement, then I'll work on modifying the value task detection and see how that works out.

[stephentoub]

If this seems like a reasonable improvement

Thanks, Andy. That's great, and should address my case. If it can subsequently be made to eliminate the copy when inlined, all the better, but not having that won't block me.

[stephentoub]

@AndyAyersMS, this is essentially the change I'd like to be able to make:
stephentoub/coreclr@bd1003c

[AndyAyersMS]

Had something like that in my fork AndyAyersMS/coreclr@435eb72.

Looking at diffs now....

[AndyAyersMS]

PR for this is out for review: dotnet/coreclr#14698.