Date: Mon, 05 Aug 2002 16:29:35 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Darren Pilgrim <dmp@pantherdragon.org> Cc: Jason Andresen <jandrese@mitre.org>, Dmitry Morozovsky <marck@rinet.ru>, hackers@freebsd.org Subject: Re: -fomit-frame-pointer for the world build Message-ID: <3D4F0A5F.9B76573F@mindspring.com> References: <20020802212841.R58905-100000@woozle.rinet.ru> <3D4AC526.4CD399B3@mindspring.com> <3D4C8464.A2F4775A@pantherdragon.org> <3D4CC81F.94526C8A@mindspring.com> <3D4EA466.C1289F0F@mitre.org> <3D4EF091.EA1C91D3@pantherdragon.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Darren Pilgrim wrote: > > > The claimed savings are fictions. They are function call > > > overhead savings assuming an average number of arguments and > > > related pushed values, and they apply only to the call process > > > itself. Most time in programs is spent in running, not calling > > > functions, so if you expect an elimination of "18% overhead" > > > to make you programs that much faster, you are dreaming. > > > > On the other hand, -fomit-frame-pointer is the only optimization > > beyond -O in gcc that actually seems to offer any sort of speedup > > for me. I've seen 10 to 20% reduction in runtime on some programs > > with -fomit-frame-pointer. It's the only specific optimization I > > bother with anymore. > > What, if anything, have you come across that won't compile/run properly > when you use -fomit-frame-pointer? Not that this question has anything to do with the stuff you are quoting before asking it... If you attamept to mix code that does callee pop or tail call optimization (e.g. in a library) with code that omits the frame pointer, or vice versa, then either the caller is going to push something that is never popped, or the callee is going to pop something that is never pushed. For hand coded assembly functions, it's not possible to make it obey the options which control this (e.g when it is not the caller which does both the pushing and popping of arguments). In other words, -fomit-frame-pointer assumes that all function interfaces are reflexive. This is particularly an issue when using foreign ELF objects that ar distributed binary only by third parties (e.g. some of the Winmodem driver modules, binary drivers from vendors, like ETInc., etc.). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D4F0A5F.9B76573F>