Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Jan Kotas
    @jkotas
    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.
    Aleksey Kliger (λgeek)
    @lambdageek
    Well that makes sense since we're solving roughly the same problem. :smile:
    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
    Aleksey Kliger (λgeek)
    @lambdageek
    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.
    Jan Kotas
    @jkotas
    Agree that the interface to the runtime is custom. It is hard to reuse it between different runtimes or execution environments.
    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.
    Aleksey Kliger (λgeek)
    @lambdageek
    agree completely. it was frustrating reinventing that wheel - much better to share.
    Bernhard Urban-Forster
    @lewurm
    damn it :smile: that looks very similar indeed
    @jkotas how is IlToWebAssemblyImporter hooked into the runtime? is there some equivalent to ICompiler?
    Ken Domino
    @kaby76
    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.
    Aleksey Kliger (λgeek)
    @lambdageek
    @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.
    Jan Kotas
    @jkotas
    @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.
    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.
    Bernhard Urban-Forster
    @lewurm
    that's an interesting example. my naive answer would be "can't it provide both offset and mangled field name?", but I assume there are more things like that :slight_smile:
    so... for RyuJIT. is it used as a JIT or rather as an AOT compiler @jkotas ?
    Jan Kotas
    @jkotas
    (JIT prototype in CoreRT is very rough/incomplete.)
    Bernhard Urban-Forster
    @lewurm
    interesting. thank you for all the pointers! :smile:
    Michal Strehovský
    @MichalStrehovsky
    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
    Ken Domino
    @kaby76
    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
    Morgan Brown
    @morganbr
    @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.
    Alexander Kyte
    @alexanderkyte
    Is there any plan to make the current JIT/AOT compiler/runtime implement the ICompiler interface? I think that would be great for code quality.
    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
    Aleksey Kliger (λgeek)
    @lambdageek
    @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
    Ken Domino
    @kaby76
    @morganbr Please look at this example https://1drv.ms/w/s!Atb3HX_AxX9ZgahHi4Fq0UtPufWPDw .
    Alexander Kyte
    @alexanderkyte
    @lambdageek so this is for the JIT I imagine. Has AOT or interp been shoehorned into this?
    Aleksey Kliger (λgeek)
    @lambdageek
    Not yet. for hack week we just focused on the jit.
    Aleksey Kliger (λgeek)
    @lambdageek
    the mjit branch is starting to fall behind master a fair bit. I'm going to try to merge the latest master changes into the branch. will push if looks clean.
    Miguel de Icaza
    @migueldeicaza
    Love it
    I would love to get the interface merged
    Alfonso² Peterssen
    @mukel
    This is awesome,
    Graal
    Alfonso² Peterssen
    @mukel
    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.
    Alexander Kyte
    @alexanderkyte
    @lambdageek how is the mjit interface going? Have we merged it? Which files in-tree are associated with it?
    Aleksey Kliger (λgeek)
    @lambdageek
    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.
    Alexander Kyte
    @alexanderkyte
    Hopefully one day there will be a platform requirement one day that is best served by productizing this. It’s a design that will make it easier to isolate and test things like call dispatch and intrinsics
    Bernhard Urban-Forster
    @lewurm
    I love the idea of making it a mono experiment :+1: (as a reference: mono/mono#10878 )
    Alexander Kyte
    @alexanderkyte
    @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
    Alexander Kyte
    @alexanderkyte
    @kaby76 how does Campy represent generics?
    Ken Domino
    @kaby76
    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
    Alexander Kyte
    @alexanderkyte
    We should discuss documenting an interface for our AOT code for campy to implement if you’re interested @kaby76. I think @vargaz and @kumpera might be interested in that discussion.
    Alexander Kyte
    @alexanderkyte
    @lambdageek are we doing anything about mjit for the meeting?