Сегодня сотрудник Microsoft анонсировал проект 
LLILC — новый проект для трансляции MSIL в байткод LLVM, предназначенный пока главным образом для инфраструктуры CoreCLR. В ближайшее время он может быть использован для JIT-компиляции, а в дальнейшем и для формирования прекомпилированных сборок (Ahead-of-Time) средствами .NET Native.
Несмотря на то, что в CoreCLR уже есть свой JIT, планируется расширить поддержку различных платформ за счёт LLVM. Новый JIT использует тот же набор внутренних API, что и RyuJIT и бесшовно его заменяет. Таким образом новый JIT позволит .NET-коду выполняться на всех поддерживаемых LLVM-платформах, на которые можно портировать CoreCLR.
На текущий момент реализация позволяет скомпилировать порядка 90% методов CoreCLR и откатиться к RyuJIT в остальных случаях, при этом при запуске на платформе Windows уже проходят поставляемые с CoreCLR тесты. Это связано так же с тем, что LLVM для нормальной поддержки CLR нуждается в некотором, допиливании (которое будет проводиться их же силами), без которого невозможно сделать
Состояние проекта на текущий момент напоминает уровень поддержки LLVM в Mono, где так же потребовалисьпатчи на LLVM и так же удаётся скомпилировать лишь часть методов (в Mono происходит откат к обычному бакэнду компиляции в случаях наличия конструкций try/catch и вызовов методов интерфейса).
Стоит так же отметить имеющийся проектSharpLang, перегоняющий в LLVM-байткод скомпилированные dll-ки с MSIL внутри. Отличается тем, что живёт со своим порезанным рантаймом.
LLILC — новый проект для трансляции MSIL в байткод LLVM, предназначенный пока главным образом для инфраструктуры CoreCLR. В ближайшее время он может быть использован для JIT-компиляции, а в дальнейшем и для формирования прекомпилированных сборок (Ahead-of-Time) средствами .NET Native.Несмотря на то, что в CoreCLR уже есть свой JIT, планируется расширить поддержку различных платформ за счёт LLVM. Новый JIT использует тот же набор внутренних API, что и RyuJIT и бесшовно его заменяет. Таким образом новый JIT позволит .NET-коду выполняться на всех поддерживаемых LLVM-платформах, на которые можно портировать CoreCLR.
На текущий момент реализация позволяет скомпилировать порядка 90% методов CoreCLR и откатиться к RyuJIT в остальных случаях, при этом при запуске на платформе Windows уже проходят поставляемые с CoreCLR тесты. Это связано так же с тем, что LLVM для нормальной поддержки CLR нуждается в некотором, допиливании (которое будет проводиться их же силами), без которого невозможно сделать
- Оптимизации неявных проверок типов, нужных для типобезопасности в C#.
- Точную сборку мусора
- Особенности обработки исключений
Состояние проекта на текущий момент напоминает уровень поддержки LLVM в Mono, где так же потребовались
патчи на LLVM и так же удаётся скомпилировать лишь часть методов (в Mono происходит откат к обычному бакэнду компиляции в случаях наличия конструкций try/catch и вызовов методов интерфейса).Стоит так же отметить имеющийся проект
SharpLang, перегоняющий в LLVM-байткод скомпилированные dll-ки с MSIL внутри. Отличается тем, что живёт со своим порезанным рантаймом.
stalkerg
Это не только проблема Mono/LLILC, для Pyston так же их нужно много и никто не говорит когда их вольют в master. Кроме того не видел новых новостей по VLIW архитектур для которых LLVM оказался не эффективным (вспоминаем почему внедрили SB для Gallium R600).
т.е. LLVM хорош но всё же во многом полуфабрикат который ещё нужно хорошо допиливать для немного нестандартных решений.
Halt
Насколько я знаю проблемы с VLIW у LLVM в основном в недостаточном развитии механизма SLP. Ну и основной векторизатор тоже есть куда улучшать.
stalkerg
Насколько я знаю векторизатор для этих целей надо кардинально улучшать. Но в целом вы конечно правы.