6 ms·

LLILC – LLVM-Based Compiler for .NET CoreCLR

220 points by mjsabby 11y ago

mjsabby 11y ago
Mailing list post: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084459.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084459... And also check out LLVMSharp -- http://www.llvmsharp.org http://www.llvmsharp.org which gives LLVM access to .NET Disclaimer: I'm involved in both projects.
- pflanze 11y ago
  I'm not a .NET user (yet) and have found the readme to be somewhat cryptic: > LLILC is an LLVM based MSIL Compiler - we pronounce it 'lilac' - with a goal of producing a set of cross-platform .NET code generation tools. Today LLILC is being developed against dotnet/CoreCLR for use as a JIT, but an ahead of time (AOT) compiler is planned for the future. The mailing list post is a bit clearer to my mind, and I'm now rewording the above in "layman's language" as follows, but I may still be wrong (please correct me): "Today, LLILC is a modified version of CoreCLR (= .NET Core, which is the part of .NET which was open sourced by Microsoft in November 2014) where the code generation backend is replaced with LLVM (but still working as a JIT). We're also planning to implement an ahead of time compiler for MSIL (= CIL, which is what the .NET bytecode is a form of), also using LLVM, but then perhaps forgoing the use of (most of?) CoreCLR. The aim is also to make it possible to use the wide array of tools available in the LLVM ecosystem, such as code analyzers."
- chadzawistowski 11y ago
  Just because I was confused and others might be as well: LLVMSharp provides C# bindings to LLVM's C interface. It does not allow LLVM projects to use dotnet code.
taspeotis 11y ago
I'm surprised it's hosted by the .NET Foundation. I feel the .NET Foundation operates somewhat independently from Microsoft, but there is a large alignment with what Microsoft wants. Using LLVM feels like a departure from some of the things they're working on now. Some blog posts I have read on the MSDN Developer Tools Blogs suggested Microsoft was already working on their own AOT compiler, this statement seems to suggest LLILC has not been developed for this purpose yet. So it's an independent project? > Today LLILC is being developed against dotnet/CoreCLR for use as a JIT, but an ahead of time (AOT) compiler is planned for the future Which doesn't make much sense to me, unless Microsoft is planning on ditching their existing AOT work for LLVM. (Fine by me, LLVM is quite nice.)
- mjsabby 11y ago
  Having multiple code generators is not mutually exclusive, and this effort does not mean MSFT is ditching any existing AOT (or for that matter JIT) compiler projects. One of LLILC's major objective is give the community an MSIL frontend for LLVM. This allows a JIT or an AOT compiler to take any C# program written for the .NET Core class libraries to run on any platform that CoreCLR can be ported to and that LLVM will target.
  - BruceM 11y ago
    This seems like it would be an interesting alternative to il2cpp from the Unity folks as a path towards compiling C# code to run on asm.js in the browser.
    - rescendent 11y ago
      very interesting :)
  - taspeotis 11y ago
    > Having multiple code generators is not mutually exclusive, and this effort does not mean MSFT is ditching any existing AOT (or for that matter JIT) compiler projects. Of course not. But why spread your effort across two projects that duplicate functionality when you could focus on one?
    - mjsabby 11y ago
      Have a look at the FAQ: https://github.com/dotnet/llilc/wiki/LLILC-FAQ https://github.com/dotnet/llilc/wiki/LLILC-FAQ Q: How does LLILC relate to the .NET Native work? A: .NET Native provides a broad tool-chain, targeting Windows. The LLILC AOT could be used as the compiler component of .NET Native to target other platforms. Since LLVM can run on Windows, you could also use it as your AOT compiler for multiple platforms (including Windows) once LLILC gets there.
- kasajian 11y ago
  I've never been surprised at Microsoft attempting to solve the same or similar problem through different channels. They like to have competing projects and see which one evolves and wins... Perhaps that explains it.. Rather than say "No" to something might be the winner.
ksec 11y ago
It seems the pace of .Net improvement is moving much faster then the JVM land. What are the chances of Enterprise switching to .Net instead of Java?
- azakai 11y ago
  .NET improving faster than the JVM would be a very hard thing to measure or even estimate. There are very exciting and impressive things happening in JVM land, for example Graal and Truffle.
  - bitcrusher 11y ago
    Except, in both of the examples you cite, .Net has had those features since day 1 ( more than 13 years now ). I think it's pretty disingenuous to say those things are hard to measure or even estimate. Java and C# are close enough that you actually CAN measure them in a pretty useful way. Java has been behind the curve for YEARS as compared to .Net with perhaps the exception of the cross platform aspects and the more permissive licensing.
    - azakai 11y ago
      Not sure we're talking about the same thing. To my knowledge no other ecosystem has anything close to Graal and Truffle at this point, much less "since day 1" of .NET. The closest thing I can think of is PyPy, which like Graal+Truffle lets you write a dynamic language in a high-level way, but still get specialized JIT compilation "for free". (In PyPy you write an interpreter, in Graal+Truffle it's more declarative.) Both PyPy and Graal+Truffle achieve state of the art performance. I'm not aware of any dynamic language on .NET coming even close to that.
      - bitcrusher 11y ago
        As I understand it, Graal+Truffle is basically the DLR. This has been around since 2008 from Microsoft. Both IronPython and IronRuby have used this for years. The "Day 1" comment was specifically pointed at the read-between the lines for Graal, which is basically to create a real IL for Java instead of using the InvokeDynamic semantic that is currently envogue for Scala, Clojure, etc. .NET has had the multi-language one VM paradigm since day one.
jevinskie 11y ago
I wonder how this will affect Mono/Xamarian, given that LLILC has commited to providing an AoT compiler. It would nice to see a CLR frontend for LLVM that cooperates more closely with LLVM upstream. Mono's fork of LLVM is about a 3.4k line diff (mostly EH additions, few -/+ modifications) but they don't seem to actively try to upstream much. Edit: I gave up trying to build a Linux-x86_64 to Android-ARM cross-compiled Mono a year ago. The configure script didn't even think of handling bitness differences between host and target... The commerical Xamarian toolchain for AoT iOS compilation seems more mature than what is released in Mono.
- mjsabby 11y ago
  LLILC is absolutely interested in upstreaming and in fact, at least one big change (prelim COFF support for MCJIT) is already upstreamed (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150216/261289.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-...) in addition to a few smaller ones. Diffing upstream with http://github.com/Microsoft/llvm http://github.com/Microsoft/llvm will let you track what Microsoft is currently doing in its repo.
  - jevinskie 11y ago
    I'm elated to hear that. I'm eager to browse the repo tomorrow. Thanks for the feedback! =)
drawkbox 11y ago
This is somewhat similar to IL2CPP from Unity[1] with AOT is currently what is used on iOS and WebGL builds. It is still buggy and has been in development for a few years or over a year, but it does essentially the same thing, take IL and port it to C++ per platform with AOT compiling. They largely did this to go around Mono licensing from Xamarin and the export is now C++ so there can be no platform limitations or it is minimal that C++ tech would be blocked by Apple for any reason for instance like they did with JIT and Flash etc. Maybe when this has AOT it can also be useable in the same way Unity IL2CPP and Xamarin Mono are used. [1] http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/ http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-...
- Torn 11y ago
  I hope it gives the IL2CPP guys some incentive to go faster. I've been waiting so long for Unity to support a more modern .NET, and to get faster
quarkzelem 11y ago
How does the GC integration work? I've heard various (bad things) about LLVM's support for integrating a GC ..
- mjsabby 11y ago
  This wiki page details what LLILC will be doing to get GC Support as required by the CoreCLR: https://github.com/dotnet/llilc/blob/master/Documentation/llilc-gc.md#gc-support-in-llvm https://github.com/dotnet/llilc/blob/master/Documentation/ll... Andy Ayers from the LLILC team will be presenting this exact topic at the EuroLLVM developer meeting: http://llvm.org/devmtg/2015-04 http://llvm.org/devmtg/2015-04 I imagine the LLVM folks will put the meeting videos up on their website like they have in the past, and it would be an interesting video to watch if you're looking for GC specific details in LLILC.
dsfsdfd 11y ago
When will I be able to get my MVC websites running in node?
- ziahamza 11y ago
  On a side note there is already the Edge project that allows NodeJS and .Net to run in the same process. So you can run Asp.Net MVC websites with NodeJS side by side. And it runs on all platforms using Mono Runtime https://github.com/tjanczuk/edge https://github.com/tjanczuk/edge
ksherlock 11y ago
llvm used to (removed with release 2.8?) include a .net msil backend -- Maybe they could add it back and go full circle -- use LLILC to load your MSIL and compile it back to... MSIL. https://github.com/llvm-mirror/llvm/tree/svn-tags/RELEASE_27/lib/Target/MSIL https://github.com/llvm-mirror/llvm/tree/svn-tags/RELEASE_27...

220 points by mjsabby 11y ago

Mailing list post: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084459.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084459... And also check out LLVMSharp -- http://www.llvmsharp.org http://www.llvmsharp.org which gives LLVM access to .NET Disclaimer: I'm involved in both projects.

pflanze 11y ago
I'm not a .NET user (yet) and have found the readme to be somewhat cryptic: > LLILC is an LLVM based MSIL Compiler - we pronounce it 'lilac' - with a goal of producing a set of cross-platform .NET code generation tools. Today LLILC is being developed against dotnet/CoreCLR for use as a JIT, but an ahead of time (AOT) compiler is planned for the future. The mailing list post is a bit clearer to my mind, and I'm now rewording the above in "layman's language" as follows, but I may still be wrong (please correct me): "Today, LLILC is a modified version of CoreCLR (= .NET Core, which is the part of .NET which was open sourced by Microsoft in November 2014) where the code generation backend is replaced with LLVM (but still working as a JIT). We're also planning to implement an ahead of time compiler for MSIL (= CIL, which is what the .NET bytecode is a form of), also using LLVM, but then perhaps forgoing the use of (most of?) CoreCLR. The aim is also to make it possible to use the wide array of tools available in the LLVM ecosystem, such as code analyzers."
chadzawistowski 11y ago
Just because I was confused and others might be as well: LLVMSharp provides C# bindings to LLVM's C interface. It does not allow LLVM projects to use dotnet code.

taspeotis 11y ago

I'm surprised it's hosted by the .NET Foundation. I feel the .NET Foundation operates somewhat independently from Microsoft, but there is a large alignment with what Microsoft wants. Using LLVM feels like a departure from some of the things they're working on now. Some blog posts I have read on the MSDN Developer Tools Blogs suggested Microsoft was already working on their own AOT compiler, this statement seems to suggest LLILC has not been developed for this purpose yet. So it's an independent project? > Today LLILC is being developed against dotnet/CoreCLR for use as a JIT, but an ahead of time (AOT) compiler is planned for the future Which doesn't make much sense to me, unless Microsoft is planning on ditching their existing AOT work for LLVM. (Fine by me, LLVM is quite nice.)

mjsabby 11y ago
Having multiple code generators is not mutually exclusive, and this effort does not mean MSFT is ditching any existing AOT (or for that matter JIT) compiler projects. One of LLILC's major objective is give the community an MSIL frontend for LLVM. This allows a JIT or an AOT compiler to take any C# program written for the .NET Core class libraries to run on any platform that CoreCLR can be ported to and that LLVM will target.
- BruceM 11y ago
  This seems like it would be an interesting alternative to il2cpp from the Unity folks as a path towards compiling C# code to run on asm.js in the browser.
  - rescendent 11y ago
    very interesting :)
- taspeotis 11y ago
  > Having multiple code generators is not mutually exclusive, and this effort does not mean MSFT is ditching any existing AOT (or for that matter JIT) compiler projects. Of course not. But why spread your effort across two projects that duplicate functionality when you could focus on one?
  - mjsabby 11y ago
    Have a look at the FAQ: https://github.com/dotnet/llilc/wiki/LLILC-FAQ https://github.com/dotnet/llilc/wiki/LLILC-FAQ Q: How does LLILC relate to the .NET Native work? A: .NET Native provides a broad tool-chain, targeting Windows. The LLILC AOT could be used as the compiler component of .NET Native to target other platforms. Since LLVM can run on Windows, you could also use it as your AOT compiler for multiple platforms (including Windows) once LLILC gets there.
kasajian 11y ago
I've never been surprised at Microsoft attempting to solve the same or similar problem through different channels. They like to have competing projects and see which one evolves and wins... Perhaps that explains it.. Rather than say "No" to something might be the winner.

ksec 11y ago

It seems the pace of .Net improvement is moving much faster then the JVM land. What are the chances of Enterprise switching to .Net instead of Java?

azakai 11y ago
.NET improving faster than the JVM would be a very hard thing to measure or even estimate. There are very exciting and impressive things happening in JVM land, for example Graal and Truffle.
- bitcrusher 11y ago
  Except, in both of the examples you cite, .Net has had those features since day 1 ( more than 13 years now ). I think it's pretty disingenuous to say those things are hard to measure or even estimate. Java and C# are close enough that you actually CAN measure them in a pretty useful way. Java has been behind the curve for YEARS as compared to .Net with perhaps the exception of the cross platform aspects and the more permissive licensing.
  - azakai 11y ago
    Not sure we're talking about the same thing. To my knowledge no other ecosystem has anything close to Graal and Truffle at this point, much less "since day 1" of .NET. The closest thing I can think of is PyPy, which like Graal+Truffle lets you write a dynamic language in a high-level way, but still get specialized JIT compilation "for free". (In PyPy you write an interpreter, in Graal+Truffle it's more declarative.) Both PyPy and Graal+Truffle achieve state of the art performance. I'm not aware of any dynamic language on .NET coming even close to that.
    - bitcrusher 11y ago
      As I understand it, Graal+Truffle is basically the DLR. This has been around since 2008 from Microsoft. Both IronPython and IronRuby have used this for years. The "Day 1" comment was specifically pointed at the read-between the lines for Graal, which is basically to create a real IL for Java instead of using the InvokeDynamic semantic that is currently envogue for Scala, Clojure, etc. .NET has had the multi-language one VM paradigm since day one.

jevinskie 11y ago

I wonder how this will affect Mono/Xamarian, given that LLILC has commited to providing an AoT compiler. It would nice to see a CLR frontend for LLVM that cooperates more closely with LLVM upstream. Mono's fork of LLVM is about a 3.4k line diff (mostly EH additions, few -/+ modifications) but they don't seem to actively try to upstream much. Edit: I gave up trying to build a Linux-x86_64 to Android-ARM cross-compiled Mono a year ago. The configure script didn't even think of handling bitness differences between host and target... The commerical Xamarian toolchain for AoT iOS compilation seems more mature than what is released in Mono.

mjsabby 11y ago
LLILC is absolutely interested in upstreaming and in fact, at least one big change (prelim COFF support for MCJIT) is already upstreamed (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150216/261289.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-...) in addition to a few smaller ones. Diffing upstream with http://github.com/Microsoft/llvm http://github.com/Microsoft/llvm will let you track what Microsoft is currently doing in its repo.
- jevinskie 11y ago
  I'm elated to hear that. I'm eager to browse the repo tomorrow. Thanks for the feedback! =)

drawkbox 11y ago

This is somewhat similar to IL2CPP from Unity[1] with AOT is currently what is used on iOS and WebGL builds. It is still buggy and has been in development for a few years or over a year, but it does essentially the same thing, take IL and port it to C++ per platform with AOT compiling. They largely did this to go around Mono licensing from Xamarin and the export is now C++ so there can be no platform limitations or it is minimal that C++ tech would be blocked by Apple for any reason for instance like they did with JIT and Flash etc. Maybe when this has AOT it can also be useable in the same way Unity IL2CPP and Xamarin Mono are used. [1] http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/ http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-...

Torn 11y ago
I hope it gives the IL2CPP guys some incentive to go faster. I've been waiting so long for Unity to support a more modern .NET, and to get faster

quarkzelem 11y ago

How does the GC integration work? I've heard various (bad things) about LLVM's support for integrating a GC ..

mjsabby 11y ago
This wiki page details what LLILC will be doing to get GC Support as required by the CoreCLR: https://github.com/dotnet/llilc/blob/master/Documentation/llilc-gc.md#gc-support-in-llvm https://github.com/dotnet/llilc/blob/master/Documentation/ll... Andy Ayers from the LLILC team will be presenting this exact topic at the EuroLLVM developer meeting: http://llvm.org/devmtg/2015-04 http://llvm.org/devmtg/2015-04 I imagine the LLVM folks will put the meeting videos up on their website like they have in the past, and it would be an interesting video to watch if you're looking for GC specific details in LLILC.

dsfsdfd 11y ago

When will I be able to get my MVC websites running in node?

ziahamza 11y ago
On a side note there is already the Edge project that allows NodeJS and .Net to run in the same process. So you can run Asp.Net MVC websites with NodeJS side by side. And it runs on all platforms using Mono Runtime https://github.com/tjanczuk/edge https://github.com/tjanczuk/edge

ksherlock 11y ago

llvm used to (removed with release 2.8?) include a .net msil backend -- Maybe they could add it back and go full circle -- use LLILC to load your MSIL and compile it back to... MSIL. https://github.com/llvm-mirror/llvm/tree/svn-tags/RELEASE_27/lib/Target/MSIL https://github.com/llvm-mirror/llvm/tree/svn-tags/RELEASE_27...