ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Enable build with PGO (profile-guided optimization) | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Vitaly Chikunov <vt> |
| Component: | rpm-build | Assignee: | placeholder <placeholder> |
| Status: | NEW --- | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P5 | CC: | arseny, glebfm, imz, iv, ldv, vt |
| Version: | unstable | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
|
Description
Vitaly Chikunov
2021-07-30 23:35:23 MSK
Есть идея делать %prep + %build да раза, первый раз в optflags добавляется: -fprofile-generate -fprofile-dir=/tmp/pgo -fprofile-update=atomic второй раз: -fprofile-use -fprofile-dir=/tmp/pgo -fprofile-correction + между ними делается find /tmp/pgo -name '*conftest.gcda' -delete. Для профилирования используется или %check, или можно сделать макро %profile_use_exit, которое помещается в конец %build перед генерацией профиля - в первом проходе он не делает ничего, а во втором exit 0. Идея Глеба - дополнить spec секцией (скажем) %profile_generate, где находится скрипт генерирующий профиль и само наличие этой секции запускает двойной build с PGO. (В ней можно было бы, например, задавать и тип PGO с -fprofile-partial-training или без. Ну или управлять этим через макрос.) (Ответ для Vitaly Chikunov на комментарий #1) > Есть идея делать %prep + %build да раза, первый раз в optflags добавляется: > > -fprofile-generate -fprofile-dir=/tmp/pgo -fprofile-update=atomic > > второй раз: > > -fprofile-use -fprofile-dir=/tmp/pgo -fprofile-correction > > + между ними делается find /tmp/pgo -name '*conftest.gcda' -delete. (Погуглил: это какие-то особые файлы, которые мешают второй стадии.) > Для профилирования используется или %check, или можно сделать макро Я ещё подумал о получении feedback для второй сборки извне (из girar) и запуск второй сборки тоже извне. При первом прогоне некоторые rpm собираются для профилирования, т.е. негодные для публикации. Потом всякие install check-и сохраняют информацию из обговоренного места (типа /feedback/for-SRPMNAME/*). Делается второй прогон (итерация задания, где должны ещё собираться пакеты, которым это требуется), во время которого подкладывается собранная информация. Она может быть из нескольких источников (install check разных бинарных пакетов и вообщеоткуда угодно при желании), так что её надо разложить как-то так: /feedback/for-SRPMNAME/from-GENERATOR1/* /feedback/for-SRPMNAME/from-GENERATOR2/* ... Там можно сделать перед использованием на втором прогоне gcov-tool --merge разных источников информации. Возникает мысль, что для воспроизводимости сборки нужно эту использованную информацию (профиль) сохранить рядом или внутри src.rpm. Только внутри сложно, потому что тогда меняется id src.rpm, да и для разных архитектур она разная. (Ну при желании использовать для этого формат src.rpm, понятный rpmbuild, можно хранить общий для всех архитектур оригинальный src.rpm, и для каждой архитектуры ещё свой с дополнительной информацией, можно без тех Source, которые есть в оригинальном, т.е. nosrc.rpm.) * * * У меня раньше были мысли о механизме feedback из girar для второй окончательной итерации сборки в связи с желанием исключить из Provides неимпортируемые python3-модули, так чтобы лишний раз не напрягать мейнтейнеров (автоматическая вторая итерация), но и не раздувать сборочную среду (BuildRequires), усложняя граф сборочных зависимостей циклами, поэтому не делать это полностью внутри одного запуска rpmbuild. (Ответ для Ivan Zakharyaschev на комментарий #2) > /feedback/for-SRPMNAME/from-GENERATOR1/* > /feedback/for-SRPMNAME/from-GENERATOR2/* > ... > > Там можно сделать перед использованием на втором прогоне gcov-tool --merge > разных источников информации. gcov-tool merge сливает пары (этого достаточно, чтобы слить и большее множество). |
