Сегодня вам нужен реальный компилятор C, чтобы быть оптимизирующим компилятором , особенно потому, что C больше не является языком, близким к аппаратному, потому что текущие процессоры невероятно сложны ( вышли из строя , конвейерны , суперскалярны , со сложными кэшами и TLB , следовательно, нуждающийся в расписании инструкций и т.д ...). Современные процессоры x86 не похожи на процессоры i386 прошлого века, даже если они оба могут выполнять один и тот же машинный код. Посмотрите, что C не является языком низкого уровня (ваш компьютер не быстрый PDP-11), статья Дэвида Чисналла.
Мало кто использует наивные неоптимизирующие компиляторы C, такие как tinycc или nwcc , поскольку они создают код, который в несколько раз медленнее, чем может дать оптимизирующий компилятор.
Кодирование оптимизирующего компилятора сложно. Обратите внимание, что и GCC, и Clang оптимизируют некое «исходное от языка» представление кода (Gimple для GCC, LLVM для Clang). Сложность хорошего компилятора C не находится на этапе анализа!
В частности, создание компилятора C ++ не намного сложнее, чем создание компилятора C: анализ C ++ и преобразование его в некоторое внутреннее представление кода является сложным (потому что спецификация C ++ сложна), но хорошо понятна, но части оптимизации еще более сложны. сложный (внутри GCC: оптимизация среднего уровня, нейтральность исходного языка и целевого процессора, составляют большую часть компилятора, а остальная часть балансируется между интерфейсами для нескольких языков и фонами для нескольких процессоров). Следовательно, большинство оптимизирующих компиляторов C также способны компилировать некоторые другие языки, такие как C ++, Fortran, D, ... Части GCC, специфичные для C ++, составляют около 20% от компилятора ...
Кроме того, C (или C ++) настолько широко используется, что люди ожидают, что их код будет компилируемым, даже если он не совсем соответствует официальным стандартам, которые недостаточно точно определяют семантику языка (поэтому каждый компилятор может иметь свою собственную интерпретацию этого). Посмотрите также на проверенный CompCert C-компилятор и статический анализатор Frama-C , которые заботятся о более формальной семантике C.
Оптимизация - это феномен длинного хвоста : реализовать несколько простых оптимизаций легко, но они не сделают компилятор конкурентоспособным! Вам необходимо реализовать множество различных оптимизаций, а также организовать и разумно их объединить, чтобы получить конкурентоспособный компилятор. Другими словами, реальный оптимизирующий компилятор должен быть сложным программным обеспечением. Кстати, и GCC, и Clang / LLVM имеют несколько внутренних специализированных генераторов кода C / C ++. И то, и другое - огромные звери (несколько миллионов строк исходного кода, скорость роста которых составляет несколько процентов в год) с большим сообществом разработчиков (несколько сотен человек, работающих в основном полный рабочий день или по крайней мере половину рабочего дня).
Обратите внимание, что нет (насколько мне известно) многопоточного C-компилятора, даже если некоторые части компилятора могут выполняться параллельно (например, внутрипроцедурная оптимизация, распределение регистров, планирование инструкций ...). И параллельной сборки с make -jне всегда достаточно (особенно с LTO ).
Кроме того, трудно получить финансирование на кодирование компилятора C с нуля, и такие усилия должны длиться несколько лет. Наконец, большинство компиляторов C или C ++ на сегодняшний день являются свободным программным обеспечением (больше не существует рынка для новых проприетарных компиляторов, продаваемых стартапами) или, по крайней мере, являются монопольными товарами (такими как Microsoft Visual C ++ ), и для компиляторов почти требуется свободное программное обеспечение ( потому что они нуждаются в участии многих различных организаций).
Я был бы рад получить финансирование для работы над компилятором C с нуля как свободное программное обеспечение, но я не настолько наивен, чтобы верить, что это возможно сегодня!