On 09.10.19 20:28, Guillem Jover wrote:
Control: tag -1 - patch + moreinfo
Control: retitle -1 dpkg-buildflags: Add support for an optimize area for 
things like LTO

On Tue, 2019-09-17 at 14:36:44 +0200, Matthias Klose wrote:
Package: src:dpkg
Version: 1.19.7
Tags: patch

Please add an optimization area (opt, optimization) for extra optimizations
like lto (link time optimization) and pgo (profile guided optimization).

lto can be directly translated into compiler flags, as seen in the attached
patch, assuming that no lto across package boundaries is done (ensured by
the debhelper patch in #939656).  The patch assumes that just nolto can be
used to disable lto until an area is introduced in dpkg.

Some upstream packages also provide build support for lto builds, so for
these an option should be given to disable the addition to the compiler
flags (like the nolto in the proposed patch).

I take you are requesting both adding this and also enabling LTO by

the infrastructure should provide both, having the option to enable it by a flag when it's not the default, and to disable it by default, when it's enabled by default.

I'm fine with the former (even implementing that myself), but the latter
would need to go through [Q] first. And I see this can cause breakage [O]
according to the OpenSUSE people.


well, yes, it breaks a few packages, more than a handful, but not the whole archive, and you can name these packages. The question for now is how to name that option, and how to disable that on a per package basis. And we probably want to enable that for a subset of architectures first, which have been test built. So the first thing is the name, so people can disable lto, before we even consider making it the default.

It's now on by default in Suse and Fedora, and I'm evaluating a complete Ubuntu test rebuild with lto on. So there are a few things which need to be manually disabled, so I'm asking about the naming first. I don't think that lto by default is out of scope for bullseye.

pgo doesn't directly translate into compiler flags, but almost always
requires upstream support in the build system.  pgo usually is enabled by
some configure options which are specific to the upstream build.  pgo
usually requires running a profiling task, so this optimization probably
should be disabled for cross builds, otoh, the cross build then is different
to the native build (although it should create a functional identical

I don't see how dpkg can support PGO, so I'm excluding that from this
request, as it seems this would be pretty much unactionable.

The only thing it would do is to provide a common interface to enable/disable it, not an implementation.

Reply via email to