[CppCodeGen] Implement virtual delegate targets

[sergign60]

We need for implementing virtual methods calls in CppCodeGen for our applicaions. Just now we have only

./src/ILCompiler.Compiler/src/CppCodeGen/ILToCppImporter.cs

        private void ImportLdFtn(int token, ILOpcode opCode)
        {
            MethodDesc method = (MethodDesc)_methodIL.GetObject(token);

            if (opCode == ILOpcode.ldvirtftn)
            {
                if (method.IsVirtual)
                {
                    throw new NotImplementedException();
                }
            }

Are there any plans and milestones for this feature?

[sergign60]

CC: @Dmitri-Botcharnikov

[jkotas]

It should not be hard to mirror the implementation used by RyuJIT backed. You can try removing this NYI check and see where it breaks.

Microsoft CoreRT team is focused on the RyuJIT backend currently. We do not have any milestones for CppCodeGen.

[sergign60]

@jkotas thanks, I'll try it.

[lemmaa]

Microsoft CoreRT team is focused on the RyuJIT backend currently. We do not have any milestones for CppCodeGen.

@jkotas , Are there any special reasons for giving up CppCodeGen?

[jkotas]

@lemmaa We have created CppCodeGen as a proof of concept to demonstrate that the CoreRT toolchain can have wide platform reach as an option. Other related technologies in this bucket are LLVM bitcode (required on Apple watches) or WebAssembly (good chance to become a big thing for games). The wide platform reach is important for devices in particular.

Microsoft .NET Core team is focused on cloud currently. The wide platform reach is not important for cloud because of cloud is pretty much native x86/x64 with arm64 on the horizon. We are not giving up on wide platform reach. We think it is important to have as an option. We are just not paid to work on it right now.

The wide platform reach technologies come with tradeoffs. For example, it is not possible to have precise GC root scanning with CppCodeGen that is as efficient as what you can do if you target the platform natively. This performance tradeoff is ok for the devices, but not for cloud where we want to compete as high performance stack.

[lemmaa]

@jkotas Aha, I get it. In the end, enabling the ARM32 RyuJIT backend is becoming more and more important to us in every way. Thank you for your detailed explanation.

P.S. Supporting WebAssembly is really interesting. I am glad to know that you are considering it. :)

[lemmaa]

cc: @egavrin @Dmitri-Botcharnikov @hqueue @hseok-oh @parjong @ragmani

[egavrin]

@jkotas @lemmaa if CoreRT is not the favorable solution then it would be reasonable for me to concentrate on RyuJIT and ARM32 support instead.

[Dmitri-Botcharnikov]

@egavrin There is another path in CoreRT which is based on RyuJIT. It has however another issues.