>>>> Т.е не ясно, почему 1й вариант, а не 2й.
>>> Там четыре варианта в зависимости от целевого ядра.
>>> Поиграйтесь флагом -march на https://godbolt.org/z/j9q4oG
>>
>>Так варианты машинного кода не объясняют причину, почему выбрана именно такая. В моём случай "ясно", это когда я найду что-то вроде:
> Ну как-бы очевидно что компилятор руководствуется подобными правилами, которые более-менее
> скрупулезно закодированные у него внутри.Так вопрос в том, насколько эти правила адекватны железу. Когда-то мне приходилось писать __asm nop, что бы MSVC не разворачивал цикл. Этот ноп давал +10% скорости.
> С явным описанием таких правил у Штеуда достаточно плохо, по многим инструкциям
> нет даже базовой информации.
А где разработчики GCC их взяли? Может они изучают код после Intel C Compiler, или получают эмпирически? Посмотрел бумажное издание Optimization Manual, там раздел "General Optimization" почти в сотню страниц, а в текущей версии на четверть сокращён (правда, и ядра другие), вероятно, в промежуточных изданиях что-то было, чего нет в этих. Есть надежда, что кое-что собрали по крупицам.
> Если хотите поднатореть в этом больше чем позволяют официальные штеуд-мануалы и (например)
> рекомендации Agner Fog, то это болезненный и малополезный путь.
Когда на горизонте маячит Эльбрус, не вижу смысла. Просто вышеприведённый код после GCC интуитивно вызвал недоверие, было интересно, можно ли найти рациональные объяснения тем лишним командам.
>> Почему GCC не заинлайнил функцию из 5-ти строк, вызываемую из единственного места, загадка.
> Чудес не бывает.
> Вероятно, она объявлена не static и visibilty для DSO оставлен по-умолчанию, что
> заставляет GCC допускать возможность переопределения функции в другом DSO.
static inline. Вообще, LTO оптимизирует на этапе связывания, насколько понимаю, может функцию в одном из мест вызова встроить, а другое её тело экспортировать.
> Либо еще какие-то проблемы с опциями оптимизации.
Наверное. Я же сразу предположил, что GCC выигрывает в руках специалистов по GCC.
