Есть идея делать %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

сливает пары (этого достаточно, чтобы слить и большее множество).