> А что мешает этот планировщик привесить к компилятору, в качестве завершающей фазы
> оптимизации, проводимой после этапа кодогенерации?Теоретически - ничего! Даже можно как бы лучше сделать - в софт можно более сложные алгоритмы оптимизации запихать, которые в железо пихать обломно.
Практически - в этом мире есть несколько выводков компиляторов. Они проектировались и делались давно. Поэтому про VLIW они знают чуть менее чем ничего. Особенно эпичен тут продолб LLVM - супер-пупер архитектура делалась не так давно. Но про VLIW почему-то тоже ничего не знает. Хотя имели все шансы учесть. Но видимо рассказывать форумными эпплоботами про крутую архитектуру LLVM проще чем нанять вменяемого архитекта в проект.
В результате как нетрудно понять, реально существующие компилеры генерят под VLIW весьма и весьма "так себе". Что и нагибает всю идею - вместо супер-оптимизаций, компилеры со скрипом и костылями еле распираются сгенерить хоть как-то работающий код.
На примере амд: они 2 года долблись чтобы просто выжать валидную кодогенерацию для своих VLIW из LLVMного гуано. После двух лет долботни оно наконец смогло генерит шейдеры ... лишь немного тормознее чем самопальный кодогенератор, который написали сто лет назад а про оптимизацию никто и не задумывался даже. И после этого там море глюков в этом LLVM. По сей день. В аллокации регистров оно обсиpaется постоянно. Оптимальность кода - ниже всякой критики. Оно вообще понятия не имеет о такой фигне как взаимозависимости команд. Поэтому LLVM выдает что может, а отдельная фаза за ним - костылирует код, переставляя команды, до состояния когда поток станет хотя-бы технически-валидным (т.е. учитывающим взаимозависимости как указано в спеках).
А героев которые бы расперлись с ноля написать компилер который бы выжал плюсы архитектуры за все эти годы так и не нашлось...
