avr-gcc: (на первый взгляд) ненужный пролог/эпилог в простой функции

Я не уверен, что это хороший ответ, но это лучшее, что я могу дать. Сборка для функции f_u64() выделяет в стеке 72 байта, а затем снова их освобождает (поскольку при этом задействованы регистры r28 и r29, они сохраняются в начале и восстанавливаются в конце).

Если вы попытаетесь скомпилировать без оптимизации (я также пропустил флаг c++11, я не думаю, что это имеет какое-либо значение), то вы увидите, что функция f_u64() начинается с выделения 80 байтов в стеке (аналогично открывающим операторам, которые вы видите в оптимизированный код, только с 80 байтами вместо 72):

    in r28,__SP_L__
    in r29,__SP_H__
    subi r28,80
    sbc r29,__zero_reg__
    in __tmp_reg__,__SREG__
    cli
    out __SP_H__,r29
    out __SREG__,__tmp_reg__
    out __SP_L__,r28

Фактически все эти 80 байт используются. Сначала сохраняется значение аргумента x (8 байтов), а затем выполняется множество перемещений данных с использованием оставшихся 72 байтов.

После этого 80 байт освобождаются в стеке аналогично закрывающим операторам в оптимизированном коде:

    subi r28,-80
    sbci r29,-1
    in __tmp_reg__,__SREG__
    cli
    out __SP_H__,r29
    out __SREG__,__tmp_reg__
    out __SP_L__,r28

Я предполагаю, что оптимизатор заключает, что 8 байтов для хранения аргумента можно сэкономить. Следовательно, ему нужно всего 72 байта. Затем делается вывод, что все перемещения данных можно избежать. Однако он не может понять, что это означает, что 72 байта в стеке можно сэкономить.

Следовательно, я считаю, что это ограничение или ошибка оптимизатора (как бы вы это ни называли). В этом случае единственное «решение» - попытаться перетасовать реальный код, чтобы найти обходной путь или вызвать его как ошибку в компиляторе.

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

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

#define f_u64(x) ((uint64_t)(x))

Накладные расходы, которые вы видите, являются результатом Endianness того, как ЦП хранит числа. В примере, на который вы ссылаетесь в Compiler Explorer, вы выбрали Uno — этот код GCC генерирует ASM для ATmega328P (с прямым порядком байтов). Вы также сопоставляете uint64 с 8 x uint8, поэтому компилятору необходимо перевернуть старшую и младшую 32-битные части 64-битного числа... а затем вернуть их обратно при возврате. (Вы увидите, что Godbolt показывает две части разными цветами.)

Как это удалить? Именно так работает ATmega328P. Если вы выберете компилятор Raspbain на godbolt, вы увидите, что накладные расходы исчезнут, потому что порядок следования байтов на этой платформе является прямым порядком байтов.