On Mon, Aug 7, 2017 at 9:19 AM, Arjan van de Ven <ar...@linux.intel.com> wrote: > On 8/7/2017 9:16 AM, Michael Matz wrote: >> >> Hi, >> >> On Mon, 7 Aug 2017, Arjan van de Ven wrote: >> >>> wanting a framepointer is very nice and desired... >>> ... but if the optimizer/ins scheduler moves instructions outside of the >>> frame'd portion, >>> (it does it for cases like below as well), the value is already negative >>> for >>> these >>> functions that don't have stack use. >>> >>> <MPIDU_Sched_are_pending@@Base>: >>> mov all_schedules@@Base-0x38460,%rax >>> push %rbp >>> mov %rsp,%rbp >>> pop %rbp >>> cmpq $0x0,(%rax) >>> setne %al >>> movzbl %al,%eax >>> retq >> >> >> Then don't compile with -fno-omit-frame-pointer. You explicitely >> requested one, so why are you surprised to see one? > > > I'm not surprised to see one. > I'm surprised to see a useless one. > > The "perf" benefit is real, and that's why I asked for one... but the > reorder made it an expensive > 3 instruction nop for all intents and purposes. > If the pop was just before the ret, sure. It's not. > > Maybe a different angle would be for a peephole phase to just eliminate the > useless (even for those > who do want a frame pointer) push/mov/pop >
I have seen GCC generate push %rbp pop %rbp -- H.J.
