Update status

[jrmuizel]

It looks like this project is dead (no commits since June 2016). It might be worth updating the README.md with this fact and possibly rationale.

[sandreenko]

cc @russellhadley

[sirinath]

I hope this is revised since even Azul is using LLVM for their next generation JVM, there is potential for .net.

https://www.azul.com/called-new-jit-compiler-falcon/
https://www.azul.com/press_release/falcon-jit-compiler/

[sgf]

just sames like https://github.com/Microsoft/LLVMSharp

maybe we should go to wait kotlin native to support windows platform

C# is hard to native in microsoft,all of natively project is dead.

[kdriedger-simutech]

Seems like @sandreenko is working on the ObjectWriter branch: https://github.com/dotnet/llilc/tree/ObjectWriter

[markrendle]

There's a lot of work being done in [dotnet/corert](https://github.com/dotnet/corert] around native compilation, which is currently using RyuJIT as its AoT compiler but also has an "experimental" IL-to-C++-to-native compiler. That already works for simple console applications, building native self-contained executables for Windows and Linux (and possibly Mac, I haven't tried).

So there are multiple possible reasons why this project might have gone quiet:

• It has been superseded by CoreRT
• It is waiting for CoreRT to become more stable before continuing as a drop-in AoT compiler
• Microsoft's acquisition of Xamarin gives them access to Mono's more-mature LLVM Backend

[sgf]

im not sure if CoreRT used in .net Core self-contained.
but im tryed .net Core(1.1ver) self-contained.
im just do package a program which created by https://github.com/AvaloniaUI/Avalonia
but its give me about 300 dll and 50 mb Size files.
thats not a joke?

where,im just think .net Core(1.1ver) self-contained. thats just created a .net program loader.

[WinInsider]

Work on LLILC was undertaken to overtake/supersede LLVMSharp according to: https://dotnetfoundation.org/blog/2015/04/14/announcing-llilc-llvm-for-dotnet

however, seems like LLILC is kaput, and LLVMSharp kicking... what's up?

[JosephTremoulet]

what's up?

See https://github.com/dotnet/coreclr/issues/4331#issuecomment-313179155 -- in particular:

As far as an LLVM based upper tier goes -- obviously we have looked into this to some extent with LLILC, and at the time we were in frequent contact with the Azul folks, so we are familiar with many of the things they were doing in LLVM to make it more amenable to compilation of languages with precise GC.

There were (and likely still are) significant differences in the LLVM support needed for the CLR versus what is needed for Java, both in GC and in EH, and in the restrictions one must place on the optimizer. To cite just one example: the CLRs GC currently cannot tolerate managed pointers that point off the end of objects. Java handles this via a base/derived paired reporting mechanism. We'd either need to plumb support for this kind of paired reporting into the CLR or restrict LLVM's optimizer passes to never create these kinds of pointers. On top of that, the LLILC jit was slow and we weren't sure ultimately what kind of code quality it might produce.

So, figuring out how LLILC might fit into a potential multi-tier approach that did not yet exist seemed (and still seems) premature. The idea for now is to get tiering into the framework and use RyuJit for the second-tier jit. As we learn more, we may discover there is indeed room for higher tier jits, or, at least, understand better what else we need to do before such things make sense.