On Tue, Jun 24, 2025 at 10:13 PM Florian Weimer <fwei...@redhat.com> wrote: > > * 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.
I think Meta engineers are people, so your statement is not very accurate. But no offense taken :) > > The option does not have the intended effect because we do not disable > GCC's shrink-wrapping optimization. For my own education. Would -mno-omit-leaf-frame-pointer have no effect always (100%, guaranteed) because of that shrink-wrapping optimization? Or it *might not* have an effect? But even if it's 100% of the time, can't we have some projects opting out from shrink-wrapping and thus getting a benefit of -mno-omit-leaf-frame-pointer? And where shrink-wrapping optimization is active, this setting doesn't hurt, right? So I guess I'm just confused why we need to fix something that isn't broken... > > 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. Yes, that's true and is a fact of life with frame pointers. But that doesn't mean that we should artificially worsen the situation by removing leaf frame pointers, right? > > 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
