Re: Compiling x86 with and without frame pointer

[David Zaffiro <davzaffiro@netscape.net>]

>>since "-momit-leaf-frame-pointer" makes a trade-off between both
>>other options: it omits framepointers for leaf functions (callees
>>that aren't callers as well) and it doesn't for branch-functions.
> 
> 
> Which does not sound quite right for me. FP should be omitted
> only if function contains less than half dozen stack references,
> otherwise not. It does not matter whether it is a leaf function or not.

Leaf functions generally do not contain more than half dozen 
stackreferences, and are generally called more or equally often as there 
callers. The slight overhead of leaf functions that do contain a dozen 
stackreferences is much smaller than the overhead of omitting 
framepointers in /all/ branch functions including those with dozens of 
stackreferences. Maybe gcc's optimizer could be adapted in the (near) 
future to compare either speed or sizes of possibly generated code, with 
and without framepointer, if the compile is not a debug one.

But in the mean time, in most "userland" projects I've tested with, the 
-momit-leaf-frame-pointer resulted in almost te same codesize as 
compiles with framepointer, along with more or less the same speed as 
"-fomit-frame-pointer". I wouldn't know how to benchmark kernel-configs 
though, and I haven't seen anyone doing this with the framepointer 
options yet...


> OTOH, AFAIK frame pointers make debugging easier, development kernels
> are better to be compiled with fp in every func.

Honestly, I think that's a shortcoming of the debugger if that's true. 
The debugger could store the stackpointer position after a call or 
calculate it based on sub/add/push/pop's, instead of borrowing it from 
ebp.  I'm just concerned about the extra costs (in speed and size) of 
always omiting the framepointer.

(It shouldn't be impossible to debug regparm- and stdcall-functions as 
well, I wonder why this could be a problem at the moment. But just 
"omitting framepointers" at least doesn't mix up the (IMHO: somewhat 
thoughtlessly defined) i386 32-bit C-callingconvention.)