Package: debian-policy
Version: 4.6.2.0
Severity: wishlist
X-Debbugs-Cc:
debian-cr...@lists.debian.org,rb-gene...@lists.reproducible-builds.org
Hi,
more and more packages implement a technique called profile guided
optimization. The general idea is that it performs a build that is
instrumented for profiling first. It then runs a reasonable workload to
collect profiling data, which in turn is used to guide the optimizer of
a second build which is not thus instrumented. The idea is that this
second build probably is faster than a regular build.
Quite obviously this approach completely breaks cross building. It also
is unclear how it affects reproducible builds since such builds depend
on the performance characteristics of the system performing the build.
This makes it very obvious that the pgo technique has downsides that
warrant disabling it in some situations.
A number of packages have agreed on disabling such optimization when
DEB_BUILD_OPTIONS contains nopgo. I'm aware of the following packages:
* binutils
* cross-toolchain-base
* gcc-VER
* halide
* pythonVER
I'll also be filing a patch for foot to support this option.
Is this sufficient coverage to document the option already? If not, this
bug report can serve as a central point for discussing it and its
adoption.
Proposed wording:
This tag requests that any optimization performed during the build
should not rely on performance characteristics captured during the
build. Such optimization is usually called profile guided
optimization.
The proposed tag intentionally is fairly narrow. It does not cover link
time optimization. It also does not cover the case where profiling
information is recorded ahead of upload and included in the source
package[1]. In both cases, neither cross building nor reproducibility is
impacted.
As for cross builds, it is not clear to me where we want to put the
responsibility to disable pgo. At the time of this writing, most
packages automatically disable pgo when performing a cross build. On the
flip side, we could have any cross builder set nopgo like they set
nocheck already. Doing so would allow performing a pgo-enabled cross
build to i386 on amd64 while still benefiting from the larger address
space for instance. I consider this aspect to be a separate matter
though.
Helmut
[1]
https://lists.reproducible-builds.org/pipermail/rb-general/2022-June/002638.html
