LLVM против C & # 8212; ; как LLVM не может быть лучше для Haskell, чем C--?

Question

Я был взволнован тем, что LLVM достаточно низок для моделирования любой системы, и посчитал это обещанием того, что Apple его примет; но с другой стороны, Apple специально не поддерживает Haskell ;

И некоторые считают, что для Haskell было бы лучше с C-- :

  

То, что LLVM'ы не решили проблему сборки мусора с нулевыми накладными расходами   не слишком удивительно   Решая это, оставаясь агностиком модели данных   это открытый вопрос в области компьютерных наук.

- LHC не будет использовать LLVM.

Answer 1

В UNSW есть проект по переводу ядра GHC на LLVM

Помните: 10 лет назад не было ясно, что LLVM создаст всю инфраструктуру, которую С-- не смог. К сожалению, LLVM имеет инфраструктуру для переносимого, оптимизированного кода, но не инфраструктуру для хорошей поддержки языка высокого уровня, которая C-- ha (s) d.

Интересным проектом будет нацеливание на LLVM из C-- ...

<Ч>

Обновление , начиная с GHC 7, GHC использует LLVM для генерации кода . Используйте флаг -fllvm . Это улучшило числовую производительность для некоторых программ низкого уровня. В остальном производительность аналогична старой версии GCC.

Answer 2

Немного поработав с новым бэкэндом генерации кода, который манипулирует C--, я могу сказать, что есть ряд причин, по которым C-- может быть лучше, чем LLVM, а также почему они на самом деле совсем не таковы то же самое.

<Ол>

C-- работает на более высоком уровне абстракции, чем LLVM; например, мы можем сгенерировать код в C--, где указатель стека является полностью неявным, и проявить его только позднее во время процесса компиляции. Это значительно упрощает применение определенных типов оптимизаций, поскольку представление более высокого уровня допускает больше движения кода с меньшим количеством инвариантов.

Хотя мы активно пытаемся это исправить, LLVM страдает от той же проблемы, что и бэкэнд via-C: он требует от нас создания процедурных точек. Что такое proc точки? По сути, поскольку Haskell не использует классическое соглашение о вызовах / повторных вызовах, всякий раз, когда мы делаем моральный эквивалент вызова подпроцедуры, нам нужно поместить продолжение в стек и затем перейти к подпроцедуре. Это продолжение обычно является локальной меткой, но LLVM требует, чтобы она была реальной процедурой, поэтому нам нужно разбить функции на более мелкие части (каждая часть называется точкой прокрутки). Это плохие новости для оптимизаций, которые работают на уровне процедур.

C-- и LLVM используют другой подход к оптимизации потока данных. LLVM использует традиционный стиль SSA с phi-узлами: C-- использует классную среду под названием Hoopl, которая не требует, чтобы вы поддерживали инвариант SSA. Я могу подтвердить: программирование оптимизаций в Hoopl очень увлекательно, хотя некоторые типы оптимизаций (на ум приходят встраивание одноразовых переменных) не совсем естественны в этой настройке потока данных.

Answer 3

GHC теперь официально имеет бэкэнд LLVM, и оказывается, что он конкурирует с GCC и native-codegen, а в некоторых случаях даже быстрее . И проект LLVM принял новое соглашение о вызовах Дэвид Терей (David Terei) создал для Haskell LLVM, так что удивительно, что эти два проекта фактически работают вместе.

Answer 4

Одной из проблем на практике является то, что LLVM была гораздо более подвижной целью.

У GHC возникли проблемы с попыткой поддержки нескольких версий LLVM. Существует активное обсуждение рассылки ghc-dev список об этом.

Кстати, в настоящее время бэкэнд llvm в ghc выполняется после того, как Haskell переведен на язык cmm (который, я считаю, в основном просто C - расширен с некоторыми регистрами из языка STG), и из-за вышеупомянутого Для устранения трудностей выполняются избыточные оптимизации, что замедляет компиляцию.

Кроме того, исторически, и в настоящее время AFAIK, проект LLVM не имеет приоритета для предоставления портативной платформы, и некоторые разработчики высказывают мнение, что он - это IR компилятора, а не форма переносимого языка ассемблера .

IR LLVM, который вы пишете для одной целевой цели, может вообще не быть полезной для другой целевой цели. Для сравнения, сайт C-- фактически называет его портативной сборкой. " Вы были бы намного счастливее с одним переносимым языком ассемблера, который мог бы ... " цитата из их веб-сайта . На этом веб-сайте также упоминается интерфейс времени выполнения для упрощения переносимой реализации сбора мусора и обработки исключений.

Таким образом, вы можете думать о C-- как о переносимом общем фундаменте для всех внешних интерфейсов, который имеет немного больше общего с CIL и Java-байт-кодом, а также о LLVM IR как о выразительном общем фундаменте для всех ваших бэкэндов, которые облегчает объединение низкоуровневых оптимизаций, общих для нескольких целей. LLVM IR также предоставляет дополнительный бонус, заключающийся в том, что проект LLVM реализует многие из этих низкоуровневых оптимизаций. При этом, в некотором смысле, LLVM IR на самом деле можно считать более высоким уровнем, чем C--, например, LLVM IR имеет разные типы, где, как и в C--, все это просто битовые векторы.