@SingleAccretion, I tried having copilot implement your proposed JIT-EE API. Looking at it now, I'm thinking we may want to explicitly pass a count arg after the types arg instead of making it implicit with a null terminator, what do you think? Should we have it accept a SIG_INFO instead of passing a count and type pointers? Were you thinking something else?

I'm thinking we may want to explicitly pass a count arg after the types arg instead of making it implicit with a null terminator

Yes, that is a good pattern for such APIs (note CorInfoType[] - of course, in C you have to lower that to pointer + length).

Is it fine to land this without an implementation? Or do I need to implement the API before it's ready for review? cc @AndyAyersMS

Is it fine to land this without an implementation? Or do I need to implement the API before it's ready for review? cc @AndyAyersMS

How sure are you about the API shape? Usually when I do something like this, I like to plumb through some of the implementation to build confidence that I have the right shape.

API shape

One thing we may think about is future-proofing the API for vectors. We don't have a CorInfoType for vectors, so it may be a good idea to add an enum like we already have with WasmValueType for just the WASM types.

API shape

One thing we may think about is future-proofing the API for vectors. We don't have a CorInfoType for vectors, so it may be a good idea to add an enum like we already have with WasmValueType for just the WASM types.

Yeah, I was thinking about vectors and wondering what the best solution is for those. Could we pass an array of CLASS_HANDLEs instead and then crossgen/the EE is responsible for figuring out the calling convention for things like singleton structs?

Class handles have the same problem as things like CORINFO_SIG_INFO - they're 'hard to come by'. In the Jit, we only have handles for "non-primitive structs". I. e. the opposite of what we want for this API.

I'm working on adding a new derived type of ObjectNode for a wasm type signature and making R2R create one and return a handle for it.

One thing we may think about is future-proofing the API for vectors. We don't have a CorInfoType for vectors, so it may be a good idea to add an enum like we already have with WasmValueType for just the WASM types.

Should this just take the encoded wasm signature of the type (using wasm encoding)? It would save us from problems with encoding the type one way and then re-encoding it in a different way on the other side.

Should this just take the encoded wasm signature of the type (using wasm encoding)? It would save us from problems with encoding the type one way and then re-encoding it in a different way on the other side.

It could be a blob of bytes. I am not sure it would be a big saving in terms of coupling since we need to produce signatures in the managed compiler as well, straight from a MethodDesc, and that computation must match what the Jit would produce for the same method. We could use binary-encoded signatures for both, but using a more "expanded" exchange type seems more natural.

we need to produce signatures in the managed compiler as well, straight from a MethodDesc

Where do we need to do that?

Where do we need to do that?

There are two main places:

1. Each defined function has a type. Currently we produce them in the object writer. This is not hard to fix if we wanted to move this responsibility to the Jit (it would produce a type signature for each compiled method body).
2. Undefined imported functions. In the R2R context we will probably have few if any, but in the more general NAOT case you can import random RuntimeImportMethodNodes with managed signatures. You can't really drive this from the Jit side unless you accept needing to, when producing a reloc to a direct call, also in some way "associate" that direct callee with a signature.

There are also probably going to be cases with hand-emitted WASM where we will need to produce hand-crafted signatures that correspond in some fashion to their managed callees, which at that point may be yet to be compiled. This can be solved by delaying the signature realization and assuming the callee is going to be a part of the current compilation, and we will be able to retrieve the Jit-produced signature at object writing time. That's more complexity, however.

OK, I plumbed things through at a basic level and verified that the Wasm emitter can get a handle back from the JIT-EE API for a zero-length list of types. Is there more I should do here?

@dotnet/jit-contrib I think this is ready for review now. The plan is to immediately work on further changes to the object writer and R2R after this (together with Adam) to start wiring up relocations that use these new type symbol nodes to emit type indices into our output.