On Sat, Jun 30, 2018 at 12:01 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Sat, Jun 30, 2018 at 1:49 AM Ingo Molnar <mi...@kernel.org> wrote: >> >> --- a/arch/x86/entry/entry_32.S >> +++ b/arch/x86/entry/entry_32.S >> @@ -477,7 +477,7 @@ ENTRY(entry_SYSENTER_32) >> * whereas POPF does not.) >> */ >> addl $PT_EFLAGS-PT_DS, %esp /* point esp at pt_regs->flags */ >> - btr $X86_EFLAGS_IF_BIT, (%esp) >> + btrl $X86_EFLAGS_IF_BIT, (%esp) >> popfl > > Ho humm. Just looking at this patch, my reaction was "why isn't this > an 'andl $~X86_EFLAGS_IF' instead"? > > Yeah, I guess the 'andl' is two bytes longer (due to the 32-bit > constant - because IF is bit 9, you can't use a byte constant, and you > don't want to get a partial word write just before the popfl). > > But btr is really pretty heavy operation for older CPU's (it's gotten > better, but 32-bit code presumably cares more about the older CPUs). > > It really doesn't matter, I guess. The btr goes back to commit > c2c9b52fab0d ("x86/entry/32: Restore FLAGS on SYSEXIT"). > > Andy? >
BTR is way more leet than AND! Seriously, though, I've never really tried to shave cycles off the 32-bit code, and BTR is shorter, and I didn't spend more than about one brain cycle thinking about it. I guess that BTR has a more complicated flags pipeline (the output flags depend on the input, not just the output) and probably uses some more complicated ALU circuit as compared to ANDL. --Andy