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
