Обнаружил сегодня, что в Кейле крайне нежелательно использовать функции std::min и std::max. Как и любые инлайн функции, которым передаётся ссылка на переменные интегрального типа.
Во-первых, если не включён режим оптимизации по времени, Кейл не инлайнит даже очень короткие функции, которые заинлайнить и короче и быстрее, чем выносить. По этой причине включение оптимизации по времени может давать и более короткий код .
Во-вторых, даже если функция с параметром-ссылкой инлайнится, любая переменная, переданная в инлайн функцию по ссылке, будет принудительно размещена в памяти на стеке, а не в регистре, даже когда в этом нет никакой необходимости!

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

Ну, это вы загнули. Не все постоянно куда-то опаздывают и считают наносекунды
И вообще, идеальных компиляторов не бывает. Поменьше заглядывайте в дизассемблер, и жизнь наладится

Однако, я заметил, что мой МК непропорционально много времени проводит в одном часто вызываемом обработчике прерывания, несмотря на -O3 оптимизацию, заглянул в его листинг и... OMG! Пришлось сделать свой вариант min/max без ссылок.

Быстрый обработчик прерывания на Си++? Боюсь, компиляторы до этого ещё не доросли. Собственно, топик именно об этом

А почему бы и нет? В нём же не используются исключения и даже конструкторы. Других серьёзных претензий к кодогенерации нет.

Ваши опасения напрасны.

Доросли. Вместе с Сишными где-то к концу 90x.

А с чего бы ему инлайнить если нет указаний инлайнить? Сделано это очевидно почему - для удобства отладки.

Потому, что включён режим максимальной оптимизации - O3, функции std::min/std::max определены с inline, и компилятор должен бы видеть, что эти функции с подстановкой реализуются короче, чем с вызовом, не говоря о том, что быстрее.

Напишите в форум ARM - пусть они точно ответят. Здесь никто не ответит за ARM.