Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why does GCC drop the frame pointer on 64-bit?

What's the rationale behind dropping the frame pointer on 64-bit architectures by default? I'm well aware that it can be enabled but why does GCC disable it in the first place while having it enabled for 32-bit? After all, 64-bit has more registers than 32-bit CPUs.

Edit:

Looks like the frame pointer will be also dropped for x86 when using a more recent GCC version. From the manual:

Starting with GCC version 4.6, the default setting (when not optimizing for size) for 32-bit Linux x86 and 32-bit Darwin x86 targets has been changed to -fomit-frame-pointer. The default can be reverted to -fno-omit-frame-pointer by configuring GCC with the --enable-frame-pointer configure option.

But why?

like image 740
asdf Avatar asked May 23 '11 16:05

asdf


People also ask

What does FNO omit frame pointer do?

The -fno-omit-frame-pointer option instructs the compiler to store the stack frame pointer in a register.

Is frame pointer necessary?

Since the compiler can keep track of what's going on with the stack at any point in time, the frame pointer isn't strictly necessary. You can compile code to use the stack pointer exclusively with the -fomit-frame-pointer option to gcc.

What is stack frame in assembly?

A stack frame is a memory management technique used in some programming languages for generating and eliminating temporary variables. In other words, it can be considered the collection of all information on the stack pertaining to a subprogram call. Stack frames are only existent during the runtime process.


1 Answers

For x86-64, the ABI (PDF) encourages the absence of a frame pointer. The rationale is more or less "we have DWARF now, so it's not necessary for debugging or exception unwinding; if we make it optional from day one, then no software will come to depend on its existence."

x86-64 does have more registers than x86-32, but it still doesn't have enough. Freeing up more general-purpose registers is always a Good Thing from a compiler's point of view. The operations that require a stack crawl are slower, yes, but they are rare events, so it's a good tradeoff for shaving a few cycles off every subroutine call plus fewer stack spills.

like image 170
zwol Avatar answered Oct 11 '22 03:10

zwol