Тестирование оптимизации кода-генератора - PullRequest
19 голосов
/ 21 мая 2011

Я написал низкоуровневую оптимизацию для бэкэнда генератора кода LLVM. По сути, оптимизация переупорядочивает инструкции по сборке на уровне базового блока, чтобы позволить более поздней (существующей) оптимизации более эффективно оптимизировать результирующий код. Есть несколько тестовых случаев, которые я хотел бы проверить, и я хотел бы получить некоторые предложения для процесса тестирования, поскольку я впервые пытался сделать что-то подобное.

Вещи, которые я рассмотрел до сих пор:

  1. Скомпилируйте тесты, написанные на C, и изучите полученный ASM, созданный с использованием опции -S. Я сделал это и сравнил результаты с моей оптимизацией с исходными результатами. Этот метод позволяет мне увидеть, что моя оптимизация работает, но даже если я напишу пользовательские неисполняемые файлы C, я не смогу исследовать все желаемые тестовые сценарии упорядочивания команд.

  2. Скомпилируйте тесты для сборки LLVM, отредактируйте ее, затем опустите ASM до целевой сборки машины. Это может сработать, но из-за разного уровня абстракции между LLVM и целевым ASM, я сомневаюсь, что смогу изучить все тестовые примеры, взломав LLVM ASM, пока он не сгенерирует то, что я хочу.

  3. Используйте целевые тестовые случаи ASM в качестве входных данных для LLVM и перекомпилируйте, используя новую оптимизацию. Мне не удалось найти опцию для LLVM или gcc (большинство опций, которые принимает LLVM), чтобы принять ASM в качестве ввода.

Какова хорошая стратегия для тестирования конкретных тестовых случаев ASM при проверке низкоуровневой оптимизации компилятора ASM? Есть ли в LLVM (или gcc) некоторые параметры командной строки, которые облегчили бы этот процесс?


Редактировать: Чтобы уточнить, я не спрашиваю об автоматической генерации тестовых случаев ASM; Моя проблема заключается в том, что у меня есть эти тестовые случаи (например, ASM_before.s и reference_ASM_after.s), но мне нужно иметь возможность передать ASM_before.s в LLVM и убедиться, что оптимизированный вывод ASM_after.s соответствует известному хорошему reference_ASM_after.s. Я ищу способ сделать это без необходимости "декомпилировать" ASM_before.s в язык высокого уровня, а затем скомпилировать его (с оптимизацией) до ASM_after.s.

Ответы [ 2 ]

6 голосов
/ 22 мая 2011

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

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

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

Обычно я запускаю dhrystone, но не объявляю о победе или провале с этим.Возможно, вы захотите сделать точильный камень, если вы используете float или точильный камень с мягким fpu.

Как уже упоминалось кем-то выше, тесты самопроверки - хорошая идея.Код реального мира тоже.Например, процедуры сжатия, возьмите некоторый текст (возможно, часть книги из проекта Гутенбург), сожмите его, затем распакуйте его и сравните вывод с intput, вы можете добавить дополнительную проверку, сжимая его на платформе управления, такой как ваш хости жестко закодировать сжатый размер в тест, если сжатая тестируемая версия не совпадает, но она выдает правильный вывод, но все равно дает сбой.Я также использовал библиотеку jpeg для преобразования изображений из / в формат jpeg, если ожидается, что изображение не вернется в исходное состояние со сжатием с потерями, тогда вы можете просто сделать одну передачу и контрольную сумму или проверить размер или перенести копиюОжидаемый результат и сравнить.Aes и des шифрования и дешифрования.

Существуют тома проектов с открытым исходным кодом, которые вы можете использовать со своим модифицированным компилятором, чтобы сравнить его со стандартным компилятором или другими компиляторами.Будучи реальным кодом, это тот тип вещей, с которым ваш компилятор все равно будет использоваться.Обратите внимание, что когда вы переходите на аппаратное обеспечение Toms или другие сайты с эталонными тестами, существует множество различных тестов, время, необходимое для рендеринга чего-либо, время, необходимое для компиляции gcc или linux или выполнения поиска в базе данных, множество реальных приложений.И различные приложения получают различные оценки, очень редко, когда одна платформа / решение сметает батарею тестов.

Когда ваша производительность падает, когда вы вносите изменения, это время, когда вы проверяете ассемблер и пытаетесь выяснить, почему.Помните, что сказал Майкл Абраш (и другие), независимо от того, насколько хорошо вы думаете, что ваш ассемблер, вам все равно придется это делать.Также попробуйте сумасшедшие вещи, которые, как вы уверены, будут медленными, потому что иногда вы обнаруживаете, что они быстры по причинам, о которых вы никогда не думали.

0 голосов
/ 14 июня 2011

Является ли команда выбора LLVM тем, что вы ищете?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...