Ну в другом проекте либа отрабатывает

Привет. Я правильно понимаю, что ghc компилирует в llvm ir или в си?

И как в нём под капотом реализован расширяющийся стек?

Обычный segmented stack в хипе живущий

Сишный стек используется только для вызовов в си

Ясно. А за сегментед стек отвечает llvm с gcc или сам ghc?

Что значит отвечает?

То есть в llvm и gcc емнип можно скомпилировать программу с опцией -fsplit-stacks, при этом в самом коде ничего делать не нужно

Ну и если быть точным, то основная сборка это NCG (New code generator), и там на пути нет ни llvm, ни C

Ну и вот, добавляет ли ghc в свой выхлоп что-то связанное с сегментированными стеками

Сегментированый стек это calling convention + аллокация фреймов рантайм системой

Так что видимот ответ "добавляет"

Ну и если мне не изменяет память то split-stack ничего общего с segmented stack не имеет, но это уже не точно

у ghc нативный кодогенератор - основной. когда-то был кодогенератор через си, он постпроцессил ассемблер на выходе сишного компилятора (теперь такого бекенда нет, есть бекенд через си только для бутстрапа, он генерирует сильно более медленный код, по сравнению с нативным кодогенератором), есть не совсем доделанный бекенд через ллвм. в ир он скомпилить не может, использует ллвм как раньше сишный компилятор и построцессит его выхлоп

Под выхлопом я имею в виду именно всякий IR, а не исполняемые файлы )

А разве для хаскеля не критично то, что для каждого вызова функции аллокать новый сегмент стека - это дороговато?

На unregistered архитектурах же кажется via-c используется?

ну вот этот и есть неполноценный для бустрапа

Непонятно почему вы считате, что для каждого вызова надо аллоцировать новый семент стека

Обычный стек работает точно так же как segmented, просто в сегменте сдвинули указатель на bottom и всё