> Я уже сказал, что те, кто умеют делать качественный софт - обычно
> умеют и оптимизацию делать неплохо, только обычно почему-то не торопятся ее
> делать.

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

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

Причем здесь вообще качество софта? Речь о компиляторе же. Не мешайте все в одну кучу! Если компилятор способен генерить более быстрый код (и/или меньший по размеру, если это нужно), то такой компилятор работает эффективнее, не согласны?
То что в некоторых задачах скорость не принципиальна, не говорит вообще ни о чем, поскольку есть задачи для которых скорость весьма важна - вы что их предлагаете не рассматривать из-за того что компилятор не умеет генерить эффективный код?

> Просто вы не знаете, что еще такого возразить...

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

> clang мог бы быть любимой игрушкой, если был бы большой выбор между
> свободными компиляторами С.
> Если кто-то не любит слепо gcc - из этого еще не следует,
> что он слепо любит clang.
> Кто-то просто любит когда есть выбор.

В этом вы правы, вообще LLVM интересный проект, и clang в частности, и выбор это приятно. Но если вдруг у компилятор генерит не совсем эффективный код, то это не потому что "не нужно", просто есть куда расти.