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

Question

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

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

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

- LHC won't be using LLVM.

Answer 1

Ну, есть проект на UNSW перевести GHC сердечника к LLVM

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

Интересный проект будет предназначаться LLVM из c-- ...

---

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

Answer 2

GHC теперь официально имеет бэкэнд LLVM, и получается, что это competitive with the GCC and native-codegen and actually faster in some cases. И проект LLVM has accepted the new calling convention Дэвид Трейи, созданный для Haskell на LLVM, так удивительно, что два проекта фактически работают вместе сейчас.

Answer 3

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

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

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

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

Answer 4

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

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

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

Также, исторически и в настоящее время AFAIK, проект LLVM не имеет приоритета в предоставлении переносной платформы, и некоторые разработчики сделали точку сочленения, что она is a compiler IR and not a form of portable assembly language.

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

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