I am curious where you see this change being applied. It seems like the goal is to help packages that currently disable LTO due to memory exhaustion on koji builders. I wonder how many of those there are. Most packages that I have seen disable LTO have done so due to bugs rather than due to memory pressure. Usually these bugs turn out to be undefined behaviour in C or C++ projects that was covered up when the optimizer could only see one translation unit at a time.
I am aware that LTO has been disabled on the RISC-V shadow koji for now due to low-memory builder hardware, but surely that situation would be expected to improve before promoting RISC-V to a primary architecture. A quick search of current spec files also suggests that there are quite a few packages that disable LTO only on 32-bit targets, i.e., on i686, but this seems acceptable given the minor role of i686 packages in Fedora today. Considering 64-bit primary architectures, of the packages I have seen that do have trouble keeping memory usage small enough to fit within koji builder resource limits, the most common workarounds have been limiting the number of parallel process or, where a single process uses too much memory, reducing the debuginfo level. I’m having a hard time thinking of examples where simply disabling LTO was enough to make the difference. It may be that I just don’t know about these cases, and that there are quite a few such packages. It would be nice to have more information on this. On the other hand, if this change is less about packages that currently can’t use LTO and more about trying to save build time for packages that already successfully build with fat LTO objects, then how much builder time can be saved? And what, if any, effect on the performance of the compiled programs can be expected? If this is a compile-time/runtime performance tradeoff, it’s hard to make an informed decision without knowing what is being traded for what. -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
