The CoreRT repo has 3 different compilers hooked up to this as examples: RyuJIT, CppCodeGen and LLVM/WebAssembly. With various level of completeness - RyuJIT is the most complete one.
From my point of view this was an exercise to find out how much refactoring would have to go into Mono to get a managed compiler hooked up
And what the interface to the runtime might look like - there were different design decisions made in Mono so it wasn't entirely obvious that it would match up exactly with what we saw in CoreRT
There's also some tension between some existing EE design in Mono and what we could do from managed with LLVMSharp in a short amount of time. For example Mono's code manager is a component that manages pages of JITed code. It really wants to own that memory. But it turns out it's difficult to get LLVM to hand off JITed code without subclassing a couple of LLVM's C++ classes - not something that LLVMSharp does today. So we'll need either to generalize Mono's code manager or LLVMSharp.
Our experience has been that the type system object model (ClassInfo/MethodInfo/FieldInfo in mjit, TypeDesc/MethodDesc/FieldDesc in CoreRT) and algorithms built on top of it can be shared between different runtimes or execution environments pretty naturally.
@jkotas how is
IlToWebAssemblyImporter hooked into the runtime? is there some equivalent to ICompiler?
Starting with the BigStep example, and following the discussion, there seems to be a bit missing for a real compiler framework. While there is a meta system within Mono.Compiler that I can call at JIT time, e.g., to convert a token into field in ldsfld, etc, I'm not sure what you intend to provide to support that at runtime, e.g, the generated code for ldfld or call/callvirt need to do a lookup with a meta system. I can and do do this with my own meta system, but that's the crux of the problem for my GPU compiler.
@kaby76 that's exactly the part that is very incomplete at the moment - our intention was to add methods to
RuntimeInformation (https://github.com/lambdageek/mono/blob/mjit/mcs/class/Mono.Compiler/Mono.Compiler/RuntimeInformation.cs#L55) such as ComputeStaticFieldAddress that call into the runtime to get the required info. A more involved example (that we didn't get to during hack week) might be for a call from one method to another - in that case we would need to provide an internal call method where we could query the runtime for the address of the callee if it has already been JITed, or else cooperate on setting up a trampoline to JIT the callee the first time it is needed.
@lewurm https://github.com/dotnet/corert/blob/635cf21aca11265ded9d78d216424bd609c052f5/src/JitInterface/src/CorInfoImpl.cs#L144 is the specific bridge for RyuJIT. There are no 1:1 equivalents of mjit ICompiler or IRuntimeInformation interfaces in CoreRT. It is broken into multiple pieces in CoreRT.
The execution-model neutral methods are directly on the type system objects. For example, the equivalent of MethodInfo IRuntimeInformation.GetMethodInfoFor is MethodDesc TypeDesc.GetMethod.
The execution model and code generator specific parts are in what we call "Compilation". For example, there is https://github.com/dotnet/corert/blob/master/src/ILCompiler.Compiler/src/Compiler/RyuJitCompilation.cs or https://github.com/dotnet/corert/blob/master/src/ILCompiler.CppCodeGen/src/Compiler/CppCodegenCompilation.cs
We have not found a good way to unify the different types of compilation. They differ a lot. For example: To access a field with RyuJIT, you need an offset. To access a field with CppCodeGen, you need mangled field name that gets printed into cpp output.
so... for RyuJIT. is it used as a JIT or rather as an AOT compiler @jkotas ?
https://github.com/dotnet/corert/blob/master/src/JitInterface/src/CorInfoImpl.cs can be shared between both AOT and JIT.
The top level Compilation is not shared between AOT and JIT. https://github.com/dotnet/corert/blob/master/src/ILCompiler.Compiler/src/Compiler/RyuJitCompilation.cs is for AOT. https://github.com/dotnet/corert/blob/master/src/System.Private.Jit/src/Internal/Runtime/JitSupport/JitCompilation.cs is for JIT.
(JIT prototype in CoreRT is very rough/incomplete.)
I've restored the JIT prototype for CoreRT in dotnet/corert#6327 - once that's merged, it should be possible to step through all the managed parts that directly talk to RyuJIT in a debugger and see it compile "return 100", publish the bytes, and see AOT compiled managed code call into the generated method body. We use RyuJIT as the backend, but the execution strategy is pretty pluggable in CoreRT too
For the sake of brevity here, I've written out some of my observations from Campy and the GPU perspective: https://1drv.ms/w/s!Atb3HX_AxX9ZgaZqXV1bF6fB-ms3sA
@kaby76, that's an interesting set of observations. WRT finding liveness, one of the "interesting" constraints of WebAssembly is that it's not possible to get a pointer to the stack and there's no concept of registers. That means that we have to maintain a separate "shadow stack " that contains all of our GC references rather than relying on built-in mechanisms (phis, arguments, allocas, etc). It's true that we could use potentially use phis for non-gc references.
There’s a ton of implicit contracts that we could refine and make explicit that way
It would make unit testing a lot easier too
@alexanderkyte it's already done. but in a way you may find unsatisfying: https://github.com/lambdageek/mono/blob/mjit/mcs/class/Mono.Compiler/Mini/MiniCompiler.cs
I would love to get the interface merged
Graal
is the Java equivalent. So much easier to maintain and develop than C2. To bridge with the VM, there's JVMCI which provides a clear separation between VM and compiler, it took years to get it right. Very interesting to see this common convergence in both .NET and Java worlds.
Everything's in the https://github.com/lambdageek/mono/tree/mjit fork. Now that
MONO_EXPERIMENTS landed, I was planning on spending some time to make a PR of just the native/managed interface for mjit. In the short term I don't think I can find the time to do it, however.
@kaby76 if you’re serious about integrating Campy into mono, we should speak about what kind of support your code needs. It seems more amenable to interop with the AOT interface than as a JIT engine. I’m envisioning making some binding gen for you to call from the host-side code that Campy generates.
While I’m sure mono will need to make a few changes to support you there, they’re going to be limited to some cosmetic C entry points. Or maybe just a glue layer. I think it would be good for us to document the contract between native code and the aot-runtime.
We’ve got a ton of places where we just say
if (llvm) and it would be nice to have a reason to make that go through a consistent set of indirection
Hi Alexander, Campy currently uses a modified and updated version of DotNetAnywhere, swapping managed types at a very low level when it is supported by DNA. The C++ source code for the runtime is nearly identical for the CPU and GPU, compiled using the CUDA Toolkit for GPU and MSVC/GNU (Linux) tool chain for CPU. The code for generics is here: https://github.com/kaby76/Campy/blob/master/Campy.Runtime/Native/Generics.c. The function to create a generic instance is Generics_GetGenericTypeFromCoreType() in the C code. Since the function creates a managed type, operations on it are through the meta system. Ref types are in pinned CPU memory currently for convenience in debugging the data structures, so it is as slow as a dog. But I'll be fixing that soon (after first writing an entirely new Swig/ClangSharp/CppSharp that uses Clang+tree reg expression type maps for generating p/invoke code for CUDA + LLVM, as undocumented, magical code does nothing for me). While Campy works using DNA presently, DNA is quite grotesque. I am planning over the next year to rewrite the runtime almost completely in C# so it can run on non-NVIDIA GPUs, swapping non-blocking algorithms for blocking code that is so prevalent. -Ken