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? > specifically the push/mov/pop back to back makes no sense at all to me. > if there was meat before the pop, sure. > but when there isn't...... That can be fixed by making the pop a real scheduling barrier. If we should do that I don't know (I'd lean towards not having to do that for loopless code). Ciao, Michael.