[mono][interp] Fix unboxing during CALLI

[BrzVlad]

On interp we were storing function pointers as a simple InterpMethod. The problem is that, when loading an InterpMethod with a ldvirtftn opcode, the resulting method might need to have its this pointer unboxed, so this information needs to be embedded into the function pointer. We achieve this by passing function pointers in the interpreter via an InterpFtnDesc, which contains the need_unbox information. Each InterpMethod caches the function descriptors for both unboxing scenarios.

In order to interop with llvmonly we must use a MonoFtnDesc as a function pointer so this must point to point to an InterpFtnDesc in order to resolve normal interp calls.

Contributes to #54374

[ghost]

Tagging subscribers to this area: @BrzVlad
See info in area-owners.md if you want to be subscribed.

Issue Details

---

On interp we were storing function pointers as a simple InterpMethod. The problem is that, when loading an InterpMethod with a ldvirtftn opcode, the resulting method might need to have its this pointer unboxed, so this information needs to be embedded into the function pointer. We achieve this by passing function pointers in the interpreter via an InterpFtnDesc, which contains the need_unbox information. Each InterpMethod caches the function descriptors for both unboxing scenarios.

In order to interop with llvmonly we must use a MonoFtnDesc as a function pointer so this must point to point to an InterpFtnDesc in order to resolve normal interp calls.

Contributes to #54374

Author:	BrzVlad
Assignees:	-
Labels:	area-Codegen-Interpreter-mono
Milestone:	-

[BrzVlad]

Some observations about this change:

• I think we could avoid allocating InterpFtnDesc by just storing the InterpMethod pointer tagged whether it needs unboxing or not.
• I later noticed there is an unfortunate naming collision within the wasm pinvoke code. https://github.com/dotnet/runtime/blob/main/src/mono/wasm/runtime/pinvoke.h#L12

[lambdageek]

Some observations about this change:

So do you want to keep working on it, or take it as-is and do follow-up PRs?

• I think we could avoid allocating InterpFtnDesc by just storing the InterpMethod pointer tagged whether it needs unboxing or not.

Yea that would work too.

we could also add more mint opcodes - ldvirtftn.managed that pushes 2 values to the stack (InterpMethod, need_unbox) and calli.managed that reads 2 operands. and ldvirtftn+ldftn and calli would only work for the unmanaged calling conventions. (or alternately, add new opcodes for the unmanaged function pointers and indirect calls).