Проверка оптимизации компилятора в gcc/g ++ путем анализа протоколов ассемблирования

Я просто задал вопрос, связанный с тем, как компилятор оптимизирует определенный код C++, и я наводил справки ТАК о любых вопросах о том, как проверить, что компилятор выполнил определенную оптимизацию. Я пытался посмотреть на протокол ассемблирования, сгенерированный с g ++ (g++ -c -g -O2 -Wa,-ahl=file.s file.c) возможно видеть, что продолжается под капотом, но вывод является слишком загадочным мне. Какие методы люди используют для занятия этой проблемой и являются там какими-либо хорошими ссылками о том, как интерпретировать протоколы ассемблирования оптимизированного кода или статей, характерных для набора инструментальных средств GCC, которые говорят об этой проблеме?

11
задан 2 revs 23 May 2017 в 11:54
поделиться

7 ответов

Оптимизация GCC передает работу по промежуточному представлению Вашего кода в формате GIMPLE .

Используя семейство опций -fdump-* , Вы можете попросить GCC выдать промежуточные состояния дерева.

Например, передать это в gcc -c -fdump-tree-all -O3

unsigned fib(unsigned n) {
    if (n < 2) return n;
    return fib(n - 2) + fib(n - 1);
}

и наблюдать за тем, как оно постепенно превращается из простого экспоненциального алгоритма в сложный полиномиальный алгоритм. (Правда!)

20
ответ дан 3 December 2019 в 02:40
поделиться

Не gcc, а при отладке в Visual Studio у вас есть возможность интерперсировать ассемблер и исходники, что дает хорошее представление о том, для какого утверждения было сгенерировано. Но иногда это не совсем корректно выравнивается.

Вывод цепочки инструментов gcc и objdump -dS не имеет одинаковой гранулометричности. Эта статья о получении gcc для вывода исходного кода и ассемблера имеет те же самые опции, что и используемый вами.

3
ответ дан 3 December 2019 в 02:40
поделиться

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

Что касается общего вопроса, то я читаю (и пишу) ассемблерный язык уже более (gulp!) 30 лет, и все, что я могу сказать, это то, что для этого нужна практика, особенно для чтения вывода компилятора.

0
ответ дан 3 December 2019 в 02:40
поделиться

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

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

0
ответ дан 3 December 2019 в 02:40
поделиться

Добавление параметра -L (например, GCC -L -AHL ) может обеспечивать несколько более понятных списков.

Эквивалентный вариант MSVC является / FACS (и это немного лучше, потому что он межвесствует источником, машинным языком и двоичным, а также включает некоторые полезные комментарии).


Около трети моей работы состоит в том, что вы делаете: жонглировать C-код вокруг, а затем смотрите на вывод сборки, чтобы убедиться, что он был оптимизирован правильно (что предпочтительно просто писать встроенную сборку по всему месту. ).

Блоги на разработку игр и статьи могут быть хорошим ресурсом для темы, поскольку игры эффективно эффективно приложения в режиме реального времени в постоянной памяти - У меня есть несколько заметок , так что Mike Acton , а другие. Я обычно люблю сохранять набор инструкций Intel в окне во время прохождения списков.

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

2
ответ дан 3 December 2019 в 02:40
поделиться

Полезная техника - запуск кода под хорошим профилировщиком выборки, например, Увеличить под Linux или Instruments (со временем Profiler Instruments) Под Mac OS X. Эти профилировщики не только показывают вам горячие точки в вашем коде, но и на карте исходный код для разобранного объекта. Выделение исходной линии показывает (не обязательно смежные) линии сгенерированного кода, которая отображается на исходную линию (и наоборот). Онлайн ссылки на OPCODE и советы по оптимизации являются хорошим бонусом.

4
ответ дан 3 December 2019 в 02:40
поделиться

Zoom от RotateRight ( http://rotateright.com ) упоминался в другом ответе, но я хотел бы расширить его: он показывает отображение исходного текста на ассемблер в том, что они называют "браузером кода". Это невероятно удобно, даже если вы не являетесь экспертом по asm, потому что они также интегрировали документацию по сборке в приложение. Листинг сборки снабжен комментариями и временными параметрами для нескольких типов процессоров.

Вы можете просто открыть свой объектный или исполняемый файл в Zoom и посмотреть, что компилятор сделал с вашим кодом.

1
ответ дан 3 December 2019 в 02:40
поделиться
Другие вопросы по тегам:

Похожие вопросы: