* Andrii Nakryiko: > On Tue, Jun 24, 2025 at 11:08 AM Davide Cavalca > <dcava...@fedoraproject.org> wrote: >> >> On 2025-06-24 12:06, Florian Weimer wrote: >> > Sorry, I tried to make clear that this is regular C code compiled with >> > the -mno-omit-leaf-frame-pointer flag, like the rest of the >> > distribution. >> > >> > The only way in which glibc is special is that Wilco Dijkstra from Arm >> > has recently optimized malloc to make the happy paths as fast as >> > possible, intentionally triggering the shrink-wrapping optimization >> > through careful use of tail-calls to no-inline functions. Any other >> > packages can do the same, either manually or even automatically in some >> > cases, with profile-guided optimization. >> > >> > I think even before these malloc changes, typical workloads had like >> > 10% >> > of their profiling samples in code regions where the frame pointer was >> > not yet set up. And dropping -mno-omit-leaf-frame-pointer might not >> > even increase that percentage because short functions without memory >> > accesses are more likely to drop from profiles altogether. >> >> I agree that based on these findings it can make sense to drop >> -mno-omit-leaf-frame-pointer for glibc, but I don't this it justifies >> dropping it distro-wide, at least not without further testing and >> collecting data on the potential impact. >> > > +1, I'd start with omitting leaf frame pointers only in glibc, if we > absolutely must.
I explained multiple times that we are effectively doing this already for the hottest functions in glibc because -mno-omit-leaf-frame-pointer does not have the intended effect. It's about the rest of the distribution. I don't understand why people assume this is about glibc. I just used it as an example because it was easily accessible to me. > Unfortunately I'm not a compiler hacker, so I can't really address > -mno-omit-leaf-frame-pointer not working (at least in some > situations). But in general, do you notice a measurable effect from > removing -mno-omit-leaf-frame-pointer performance-wise? Or is there > any other associated downside to leaving it on, even if it might not > kick in in some leaf functions? > > In our (Meta) production, we have both -fno-omit-frame-pointer and > -mno-omit-leaf-frame-pointer, and I haven't seen any particular > complaints around that. So unless there is a really good reason to > drop leaf stuff, I'd keep it, of course. I think there are multiple reasons: It's an unusual configuration, not promoted by upstream and not even used by people who build with -fno-omit-frame-pointer. Fedora usually goes with upstream defaults. The option does not have the intended effect because we do not disable GCC's shrink-wrapping optimization. Due to the way the x86-64 architecture works, there is always a number of instructions at the beginning of the functions where the frame pointer has not been set up. Tools already have to accept the frame lossage, or use DWARF or heuristics to detect this situation. Thanks, Florian -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
