[dap]

We (as an industry) need to stop using -fomit-frame-pointer, at least by default. I'd be interested to see if there's any real-world workload (not a benchmark) where it makes even a measurable difference, let alone a significant one. The problem, of course, is that it destroys the ability to examine performance in production with tools like DTrace and the like. A one-time couple-of-percent improvement in some cases (which, again, would be surprising to see anyway) is not worth losing the ability to gain more performance improvements for the rest of the software's lifetime.

[byuu]

It was very beneficial on the register-starved x86, but I notice less impact on amd64.

I definitely also have a debug-mode that builds with -g and without -s -O3 -fomit-frame-pointer.

[astrange]

amd64 has enough registers that using one for the frame pointer isn't too bad.

On the other hand, some platforms don't need a frame pointer for debugging; if you emit correct unwind tables that's enough for the debugger to construct a backtrace. I haven't looked lately but am pretty sure amd64 ELF is one of them.

Also, modern gcc generates okay debug info for optimized programs such that it's much more likely you can read variables out of a crash in gdb.

[dap]

> On the other hand, some platforms don't need a frame pointer for debugging; if you emit correct unwind tables that's enough for the debugger to construct a backtrace. I haven't looked lately but am pretty sure amd64 ELF is one of them.

Working with unwind tables is more complicated and many useful debugging tools don't do so.

[dap]

It's good to have it at least in dev, but many bugs only show up in production, and performance work can only usefully be done on the shipping, optimized code.