Я был в восторге от LLVM, достаточно низкого для моделирования любой системы, и увидел, что это было многообещающим, что Apple его принимала; но опять же Apple не поддерживает Haskell;
И некоторые думают, что Haskell будет лучше с C--:
То, что LLVM'ers не решили проблему сбора мусора с нулевой загрузкой не слишком удивительно. Решая это, оставаясь агностиком модели данных является открытым вопросом в информатике.
Ну, есть проект в UNSW для перевода ядра GHC на LLVM
Помните: 10 лет назад было неясно, что LLVM создаст всю инфраструктуру, которой C... не удалось. К сожалению, LLVM имеет инфраструктуру для переносимого, оптимизированного кода, но не для инфраструктуры для поддержки высокого уровня языка, что C-- ha (s) d.
Интересным проектом было бы нацеливание LLVM на C--...
Обновление, начиная с GHC 7, GHC использует LLVM для генерации кода. Используйте флаг -fllvm. Это улучшило числовые характеристики для некоторых программ низкого уровня. В противном случае производительность похожа на старый сервер GCC.
Поработав немного с новым контентом генерации кода, который управляет C--, я могу сказать, что существует ряд причин, по которым C-- может быть лучше LLVM, а также почему theyre на самом деле совсем не то же самое.
C-- работает на более высоком уровне абстракции, чем LLVM; например, мы можем сгенерировать код в C--, где указатель стека является полностью неявным и только проявлять его позже во время процесса компиляции. Это упрощает применение определенных типов оптимизаций, поскольку представление более высокого уровня допускает большее количество движений кода с меньшими инвариантами.
Несмотря на то, что LLVM активно стремился исправить это, LLVM страдает от той же проблемы, с которой пострадал бэкэнд через C: он требует от нас создания точек проса. Что такое точки прохода? По сути, поскольку Haskell не использует классический вызов call/ret call, всякий раз, когда мы делаем моральный эквивалент вызова подпроцедуры, нам нужно нажать продолжение на стек, а затем перейти к подпроцедуре. Это продолжение обычно является локальной меткой, но LLVM требует, чтобы она была реальной процедурой, поэтому нам нужно разбить функции на более мелкие куски (каждая часть называется точкой proc). Это плохая новость для оптимизации, которые работают на уровне процедур.
C-- и LLVM используют другой подход к оптимизации потока данных. LLVM использует традиционный SSA-стиль с phi-узлами: C-- использует классную среду под названием Hoopl, которая не требует от вас поддержки инварианта SSA. Я могу подтвердить: оптимизация программирования в Hoopl очень увлекательна, хотя некоторые типы оптимизации (встраивание одноразовых используемых переменных приходит в голову) не являются наиболее естественными в этой настройке потока данных.
Теперь у GHC официально есть бэкэнд LLVM, и получается, что конкурирует с GCC и родным кодекеном и на самом деле быстрее в некоторых случаях, И проект LLVM принял новое соглашение о звонках Дэвид Трейи, созданный для Haskell на LLVM, настолько удивительно, что два проекта фактически работают вместе сейчас.
Одна из проблем на практике заключается в том, что LLVM намного более подвижная.
У GHC возникли проблемы с попыткой поддержки нескольких версий LLVM. Существует активный обсуждение в списке рассылки ghc-dev об этом.
Btw, в настоящий момент llvm backend в ghc после перевода Haskell на язык cmm (который, я считаю, в основном просто C - расширен с некоторыми регистрами из языка STG), и из-за вышеперечисленного, устранены трудности, выполняются избыточные оптимизации, которые замедляют компиляцию.
Кроме того, исторически и в настоящее время AFAIK проект LLVM не имеет приоритета в предоставлении переносимой платформы, и некоторые разработчики подчеркнули, что он компилятор IR, а не форма портативного языка ассемблера.
LLVM IR, который вы пишете для одной цели, может вообще не использоваться для другой цели. Для сравнения, веб-сайт C-- на самом деле ссылается на него как на портативную сборку. "Вы были бы намного счастливее с одним переносным языком ассемблера, который мог бы быть..." - это цитата из их веб-сайта. На этом веб-сайте также упоминается интерфейс времени выполнения, облегчающий переносимую сборку мусора и обработку исключений.
Таким образом, вы могли бы подумать о C-- как о переносной общей почве для всех фронтов, которая имеет немного больше общего с байтовым кодом CIL и Java и LLVM IR как выразительный общий язык для всех ваших бэкэндов, что облегчает унификацию низкоуровневых оптимизаций, общих для нескольких целей. LLVM IR также предоставляет дополнительный бонус, который проект LLVM будет реализовывать многие из этих низкоуровневых оптимизаций. При этом, в некотором смысле, LLVM IR действительно можно считать более высоким уровнем, чем C--, например, LLVM IR имеет разные типы, где, как и в C, все просто битовые векторы.