Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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?
    Aleksey Kliger (λgeek)
    @lambdageek
    What would you like to see?
    mazegen
    @mazegen
    Guys, first of all, thank you for this project that can help many to get deeper into the mono jit compilation process.
    Perhaps I'm not skilled in git enough - is there any way how to see only all the commit related to the mjit? This branch seems to be up-to-date with mono HEAD and it is hard to find all the relevant commits for me.
    mazegen
    @mazegen
    Or let's say it is updated from HEAD from time to time.
    For example, I'm interested in changes in method-to-ir.c
    Bernhard Urban-Forster
    @lewurm
    @mazegen: hi :smile:
    I think the easiest would be to git diff origin/master
    that said, there aren't any changes to method-to-ir.c. This file is essentially the front-end to the "Mini JIT compiler"
    the main goal of this managed JIT project is to come up with an interface, so we can plug in different JIT compilers. The main changes on the runtime side are in mini-runtime.c (yeah... the naming is... confusing)