> Кому надо? Условному контрибьютору это не надо. Условный контрибьютор пойдёт контрибьютить
> в clang с хорошей архитектурой, документацией и C++ везде, а не
> последний год, или сколько там.или в gcc, где всё ещё нормальный C, а не C++ везде и дурацкий пакованый формат IR, например. дурацкие gimple и rtl, может, приятней окажутся.
> Только тут и сравнивать не нужно, доказали — всё, чего тут ещё
> обсуждать.
ну, «доказали» — это если все ушли на фронт, пилить llvm, а gcc помер. я пока что этого не наблюдаю.
> Интересно, почему в ИСП РАН мой бывший сокурсник занимается всякими клёвыми ништяками
> над компиляторами на примере clang/llvm, а не gcc? Наверное, потому что
> первый лучше [для этой задачи]?
потому что llvm умеет меньше гитик, и за счёт этого меньше оброс костылями, например?
> Ещё придётся доказать, что изначальное планирование — единственный вариант для хреновой
> архитектуры
утверждение, что «лучше начать с нуля» — неявно это постулирует. потому что иначе никак не может быть лучше с нуля, ибо в конце получится то же самое по степени УЖОСА.
> Максимум обрезанный там список платформ, а влияние его длины (при его нетривиальности)
> на архитектуру сильно неочевидно, мягко скажем.
однако возможно.
>> штука в том, что разные
>> архитектуры могут иметь разные «бзики». у кого-то какой-то регистр только вот
>> так использовать можно, а так нельзя — и опа! в регистровом
>> аллокаторе появляется костыль для этой архитектуры.
> А не должно быть никаких костылей для этого при нормальном планировании.
я тоже хотел бы жить в мире, где всё идеально. а на практике часто получается, что не должно — а есть.
> Если от фронтенда зависит кодогенератор, то я даже не знаю, что тут
> сказать. Как capture-init из C++14, или там, не знаю, расширенный noexcept
> оттуда же вообще относится к кодогенерации? Первая вещь разворачивается на этапе
> компиляции в обычную структурку, вторая вообще по определению компил-тайм.
а так, что, например (абстрактный), при некоторых условиях и знании потрохов кодогенератора можно некоторые фичи сделать эффективней. преобразование в IR — это всё равно потеря некоторой части информации. которую кодогенератору иногда надо восстанавливать. а иногда можно — зная, как сделан кодогенератор — облегчить ему эту работу. там фичка, тут фичка — в итоге пользователи в выигрыше, потому что компилирует чуть быстрее, например, или делает код чуть лучше. а вот сам компилятор стал захламлённей.
> Локальные мегакостыли в оптимизаторе глобальную архитектуру трогать не должны, а в гцц,
> поговаривают, системные проблемы.
см. выше. в идеале оно всё, конечно, так. а на практике *может* оказаться иначе. именно поэтому я настаиваю на двух вещах: полном списке платформ и сгенерированном коде как минимум не хуже. чтобы наглядно увидеть, зря ли костыли накостылили и можно ли было без них обойтись, сохранив весь фичсет. и чего это могло стоить в других местах (скорость, память, etc).
