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

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

---

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

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 компилятора, а не формой переносимого языка ассемблера .

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

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