Methods with calli fail to inline because of unsupported opcode

[mjsabby]

Today an occurrence of the calli opcode in a method body prevents it from being even considered as an inline candidates quite early on in the Flowgraph processing, while finding basic blocks and then jump targets.

Specifically in Compiler::fgFindJumpTargets(https://github.com/dotnet/coreclr/blob/master/src/jit/flowgraph.cpp#L4767)

        case CEE_CALLI:
        case CEE_LOCALLOC:
        case CEE_MKREFANY:
        case CEE_RETHROW:
            // CEE_CALLI should not be inlined because the JIT cannot generate an inlined call frame. If the call
            // target
            // is a no-marshal CALLI P/Invoke we end up calling the IL stub. We don't NGEN these stubs, so we'll
            // have to
            // JIT an IL stub for a trivial func. It's almost certainly a better choice to leave out the inline
            // candidate so we can generate an inlined call frame. It might be nice to call getCallInfo to figure
            // out
            // what kind of call we have here.

This limitation (about inlined call frame for PInvokes) may still hold true for unmanaged calling conventions that require it, but for default calling convention targets there is no need to raise a frame (afaict).

We should be able to remove the restriction for call targets with the default cc without any major plumbing.

[mjsabby]

@AndyAyersMS

[AndyAyersMS]

Believe this was fixed by dotnet/coreclr#13756. @mjsabby can you confirm and close?

[mjsabby]

Works, thanks!