я подробно не смотрел и не специалист в теме,
интересует доки, объяснения и т.п., ну а прежде всего оценку затрат

что-то подобное есть Zylin ZPU - но сам процессор не такой как надо, а сорсы md и т.п. я не осилил

-------------

также интересно, что предпочесть LLVM (c GCC frontend) или GCC?

порт более легких компиляторов не интересен, так как нужно полную поддержку С++

-------------

MISC интересует из-за возможности сократить объем кода, но насколько это получится, без компилятора трудно определить...

Сначала к бородатому дядьке, а затрат должно быть много.
Опыт написания для TMS320-C6000. Результатом не спешат делиться

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

но мне (прошу не пинать если что) гораздо больше понравился llvm, в котором промежуточные результаты даются в виде нормального "превдоассемблера", а не мутные RTL деревья, которые в виде файла то и представить нельзя (не рекомендуется, фор дебаг онли и т.п.)

я не нашел в доках (и gcc, и llvm) объяснения как вообще влияет MD на оптимизацию (в случае gcc на финальный RTL), ну то есть в gcc это влияние (количество регистров их свойства и т.п., время исполнения команды ...) есть на каких-то шагах оптимизации
все примеры ABI похожи друг на друга - RISC процы (даже C6000 можно подогнать), а процессор со стековыми операциями???

может какой-то пинок от гуру прочистит восприятие

--------------

в LLVM я вообще не понял - оказывает ли таргет какое-то влияние на оптимизацию или свойства таргета применяются только на этапе кодогенерации....

ненашли потому что никак не влияют, -M предназначена для организации зависимостей и к кодогенерации неотоносится

бородатого дядьку к руководству я всетаки не рекомендовал - силно старый. инфраструктура внутренностей то поменялась, оптимизатор в рамках только 4 версии писали-переписывали.

а что из описания машины влияет на оптимизатор?
я так понимаю, что список абстрактных команд (standart pattern) должен быть поддержан весь - ну например
‘umulqihi3’ нужно либо описать в виде инструкции, либо в виде набора инструкций или какого-то С-шного кода, который сгенерит ассемблер для таргета, или же обеспечить библиотечный вызов такой функции - так?
а что происходит, если в define_insn для umulqihi3 стоит безусловный FAIL : компилятор сумеет сгенерить "промежуточный" код без использования умножений или так просто нельзя писать md?

я так понял, что оптимизация проводится только на уровне подбора операндов для выбраной инструкции (pattern), при этом подразумевается стандартный RISC процессор типа ARM/MIPS - так?

upd : большинство шагов оптимизатора типа субэкспрешин, констант пропагэшн, и т.п., которые выполняются при анализе исходного кода я считаю независимым от machine description.
собственно если попытаться сформулировать вопрос - где в gcc проходит граница между таргет-индепендент оптимизацией и использованием описания машины (С-макросы, патерны md и т.п.)???

мне бы хотелось понять некоторые общие моменты, которых я не нашел в документации.

---------------

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

если так, то потенциально код llvm должен быть хуже gcc, а они утверждают, что бьют gcc по скорости/размеру кода

---------------

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

--------------------

для llvm столкнулся с тем, что глючит безбожно (при использовании long long)
то есть пока gcc only