Почему LLVM имеет IR в виде сборки, а не в виде дерева IR? Или: почему проекты нацелены на LLVM IR, а не на AST Clang?

Почему промежуточное представление LLVM (LLVM IR) похоже на сборку, а не на дерево?

В качестве альтернативы, почему языковые реализации нацелены на IR LLVM, а не на AST Clang?

Я не пытаюсь задавать два разных вопроса одновременно, если так кажется. Мне просто кажется, что и клиентские и библиотечные программисты пришли к единому мнению, что API LLVM, не более и не менее, очевидно, является хорошим дизайном программного обеспечения, и мой вопрос «почему?».

Причина, по которой я спрашиваю, состоит в том, что кажется, что LLVM мог бы предоставить больше функциональности внешним интерфейсам, если бы его IR был подобен AST, потому что тогда инструменты Clang на основе AST могли бы использоваться для любого внешнего интерфейса. Альтернативно, языки, которые нацелены на IR LLVM, могут получить больше функциональности, если они нацелены на AST Clang.

Clang имеет классы и функции для создания и работы с AST, и это единственный внешний интерфейс, тесно связанный с проектом LLVM, так почему Alan-функциональность Clang является внешней по отношению к LLVM?

Вдобавок ко всему, я знаю, что Rust (rustc), D (ldc) и Haskell (GHC) могут использовать LLVM в качестве бэкэнда, но они не используют Clang AST (насколько я знаю, я мог быть неправым). Я не знаю всех внутренних деталей этих компиляторов, но, по крайней мере, Rust и D наверняка кажутся такими, что их можно скомпилировать в AST Clang. Возможно, Хаскелл тоже мог, но я гораздо менее уверен в этом.

Это из-за исторических причин (LLVM изначально была «виртуальной машиной низкого уровня», а позже появился Clang)? Это потому, что другие интерфейсы хотят иметь как можно больше контроля над тем, что они подают в LLVM? Существуют ли фундаментальные причины, по которым AST от Clang не подходит для языков, не похожих на C?

Я не хочу, чтобы этот вопрос был упражнением в чтении мыслей. Я просто хочу, чтобы это было полезно для тех из нас, кто интересуется дизайном компилятора, но еще не знаком с ним. Поскольку проекты LLVM и clang разрабатываются публично, я надеюсь, что кто-то, знакомый с разработкой этих проектов, сможет ответить или что ответ достаточно очевиден для некоторых компиляторов, и они чувствуют себя достаточно уверенно, чтобы ответить.

Чтобы предупредить некоторые очевидные, но неудовлетворительные ответы:

Да, наличие IR, подобного сборке, дает больший контроль тому, кто создает IR (возможно, X lang имеет лучшую кодовую базу и формат AST, чем clang), но если это единственный ответ, то возникает вопрос: «Почему LLVM имеет только сборку? как IR вместо древовидного IR высокого уровня и как ассемблерного IR низкого уровня? "

Да, не так сложно разобрать язык программирования в AST (по крайней мере, по сравнению с другими этапами компиляции). Тем не менее, зачем использовать отдельные AST? Если ничто иное, использование того же самого AST позволяет вам использовать инструменты, которые работают с AST (даже просто простые вещи как принтеры AST).

Да, я полностью согласен с тем, что быть более модульным - это хорошо, но если это единственная причина, то почему другие языковые реализации имеют тенденцию ориентироваться на IR LLVM вместо AST Clang?

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

Для тех, кто хочет ответить на более определенный вопрос: каковы преимущества и недостатки сборочного IR по сравнению с древовидным IR?

Здесь есть несколько взаимосвязанных вопросов, я постараюсь разделить их как можно лучше.

Почему другие языки основаны на LLVM IR, а не на AST?

Это просто потому, что clang является внешним интерфейсом C / C ++, а созданный AST тесно связан с C / C ++. Другой язык мог бы использовать его, но ему понадобилась бы почти идентичная семантика для некоторого подмножества C / C ++, что очень ограничивает. Как вы указали, разбор AST довольно прост, поэтому ограничение семантического выбора вряд ли будет стоить небольшой экономии.

Однако, если вы пишете инструментарий для C / C ++, например, статические анализаторы, то повторное использование AST имеет большой смысл, так как намного проще работать с AST, чем с необработанным текстом, если вы работаете с C / C ++ ,

Почему LLVM IR такая форма?

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

Теперь случается так, что написание оптимизаций компилятора является довольно специфической задачей и часто ортогонально дизайну языковых возможностей. Тем не менее, наличие быстро скомпилированного языка является довольно общим требованием. Кроме того, преобразование LLVM IR в ASM является довольно механическим и, как правило, неинтересным для разработчиков языков.

Следовательно, снижение языка до LLVM IR дает разработчику языка много «бесплатных вещей», которые очень полезны на практике, позволяя им сконцентрироваться на самом языке.

Будет ли полезен другой IR (хорошо, не спрашивается, но подразумевается)?

Абсолютно! AST достаточно хороши для определенных преобразований в структуре программы, но их очень сложно использовать, если вы хотите преобразовать поток программы. Форма SSA, как правило, лучше. Тем не менее, LLVM IR очень низкий уровень, поэтому большая часть структуры высокого уровня теряется (специально, поэтому она более применима). Наличие IR между AST и IR низкого уровня может быть полезным здесь. И Rust, и Swift используют этот подход и имеют высокий уровень IR между ними.