I asked Google to give me the meaning of the
Don't keep the frame pointer in a register for functions that don't
need one. This avoids the instructions to save, set up and restore frame
pointers; it also makes an extra register available in many functions. It
also makes debugging impossible on some machines.
Most smaller functions don't need a frame-pointer - larger functions MAY need one.
It's really about how well the compiler manages to track how the stack is used, and where things are on the stack (local variables, arguments passed to the current function and arguments being prepared for a function about to be called). I don't think it's easy to characterize the functions that need or don't need a frame-pointer [technically, NO function HAS to have a frame-pointer - it's more a case of "if the compiler deems it necessary to reduce the complexity of other code"].
I don't think you should "attempt to make functions not have frame-pointer" as part of your strategy for coding - like I said, simple functions don't need them, so use -fomit-frame-pointer, and you'll get one more register available for the register allocator, and save 1-3 instructions on entry/exit to functions. If your function needs a frame-pointer, it's because the compiler decides that's a better option than using frame pointer. It's not a goal to have functions without frame pointer, it's a goal to have code that works both correctly and fast.
Note that "not having framepointer" should give better performance, but it's not some magic bullet that gives enormous improvements - particularly not on x86-64, which already has 16 registers to start with. On 32-bit x86, since it only has 8 registers, one of which is stackpointer, and taking up another as the frame-pointer means 25% of register-space is taken. To change that to 12.5% is quite an improvement. Of course, compiling for 64-bit will help quite a lot too.