On Thu, Oct 31, 2024 at 12:12:30PM +0000, Richard W.M. Jones wrote: > On Thu, Oct 31, 2024 at 12:36:28PM +0100, Jakub Jelinek wrote: > > On Thu, Oct 31, 2024 at 11:26:23AM +0000, Peter Robinson wrote: > > > I seem to remember firefox uses LTO+PGO for speed ups/ > > > > > > I wonder if we could provide some rpm macros and packaging guidelines > > > to assist packagers in this process to make things more straight > > > forward and less error prone? Is something like that a reasonable > > > idea? > > > > Depends. Some packages like gcc, firefox and a few others already > > have some configure or make (or whatever build system they use) options > > to do the PGO build. Those should just use what the upstream provides and > > don't need any new rpm macros. > > Others perhaps could make use of them, but I think only conversion of a > > dozens+ of packages for PGO would reveal how those macros should look like > > and what would be helpful and what wouldn't. > > The running of a -fprofile-generate instrumented program creates > > something.c.gcda etc. files and those need to be then in the tree built > > with -fprofile-use. > > Are the *.gcda files portable or must they be consumed by the exact > same source / GCC combination? What I'm asking is, can those be > created "offline" and included later in the RPM build, even if the > code changes in between? They are dependent on the exact source and compiler options used to compile them. Basically, they add tons of counters for various events, like passing through some control flow graph edge etc. And obviously the -fprofile-generate and -fprofile-use compilations need to agree what the counters are for, so the source needs to have the same control flow graph, same order of functions, ... So no, you don't want to ship -fprofile-generate instrumented binaries/libraries in binary rpms and somehow arrange for the *.gcda files to be fed back to next build. That is what AutoFDO intends to do (one profiles non-instrumented binaries, which are then profiled and fuzzy matched to the new compilation). AutoFDO is significantly less tested than normal PGO and I'd strongly advise we avoid that. Jakub -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
