Always use CORINFO_HELP_READYTORUN_DELEGATE_CTOR optimization

[MichalStrehovsky]

Repro program (needs to be compiled with --usesharedgenerics):

using System;

internal class Program
{
    private static int Main()
    {
        TestDelegateFatFunctionPointers.Run();
        return 100;
    }


    /// <summary>
    /// Tests that we can use a delegate that points to a generic method.
    /// </summary>
    class TestDelegateFatFunctionPointers
    {
        T Generic<T>(object o) where T : class
        {
            Func<object, T> f = OtherGeneric<T>;
            return f(o);
        }

        T OtherGeneric<T>(object o) where T : class
        {
            return o as T;
        }

        public static void Run()
        {
            string hw = "Hello World";
            string roundtrip = new TestDelegateFatFunctionPointers().Generic<string>(hw);
            if (roundtrip != hw)
                throw new Exception();
        }
    }
}

fgOptimizeDelegateConstructor will abort the optimization because if (oper == GT_FTN_ADDR) is not met.

This will result in generating a normal call to the delegate's .ctor method. CoreRT doesn't have enough smarts in it to be able to tell from the function pointer how the delegate object should be laid out. The construction needs to always go through the helper. I think we're aborting because the actual address is coming from a dictionary lookup.

We're expecting the token passed to getReadyToRunDelegateCtorHelper will be the token that was ldftn'd.

[MichalStrehovsky]

Another repro, this one doesn't need shared generics:

using System;

internal class Program
{
    interface IFoo
    {
        string Frob();
    }

    class Foo : IFoo
    {
        public string Frob()
        {
            return "Hello";
        }
    }

    private static void Main(string[] args)
    {
        IFoo o = new Foo();
        Func<string> f = o.Frob;
        Console.WriteLine(f());
    }
}

This currently works, but only because RyuJIT generates a direct call to the delegate's constructor (where we make a guess that this is the instance method case). The success criteria is to be able to fix the TODO in src\Common\src\TypeSystem\IL\Stubs\DelegateMethodILEmitter.cs and stop generating a fallback body for the delegate constructor.

[MichalStrehovsky]

And another repro - with a generic virtual method - but this might have other problems after that:

using System;

internal class Program
{
    interface IFoo
    {
        string Frob<T>();
    }

    class Foo : IFoo
    {
        public string Frob<T>()
        {
            return "Hello";
        }
    }

    private static void Main(string[] args)
    {
        IFoo o = new Foo();
        Func<string> f = o.Frob<Foo>;
        Console.WriteLine(f());
    }
}

[MichalStrehovsky]

Here's another one, but this one might need a bit of work in DelegateCreationInfo.cs. It needs shared generics to hit the problem. Again, RyuJIT should make sure CORINFO_HELP_READYTORUN_DELEGATE_CTOR is used.

using System;

internal class Program
{
    class TestDelegateUnboxingStubs
    {
        class Foo
        {
            public readonly int Value;
            public Foo(int value)
            {
                Value = value;
            }

            public override string ToString()
            {
                return Value.ToString();
            }
        }

        struct Struct<T>
        {
            public readonly T X;

            public Struct(T x)
            {
                X = x;
            }

            public string MakeString()
            {
                return typeof(T[,,]).ToString() + ": " + X.ToString();
            }
        }

        public static void Run()
        {
            Struct<Foo> s = new Struct<Foo>(new Foo(42));
            Func<string> f = s.MakeString;
            if (f() != "Program+TestDelegateUnboxingStubs+Foo[,,]: 42")
                throw new Exception();
        }
    }

    private static void Main(string[] args)
    {
        TestDelegateUnboxingStubs.Run();
    }
}

[sandreenko]

Thanks for tests, I hope to start this issue today or tomorrow( it depends on my progress with DWARF debug variables).