https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87104
Bug ID: 87104
Summary: missed &, == optimization makes Emacs ~0.4% slower on
x86-64
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at cs dot ucla.edu
Target Milestone: ---
Created attachment 44595
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44595&action=edit
In this file, f and g are equivalent, but f is not optimized as well as g
GNU Emacs uses the low-order three bits of its words to represent object type
tags, and therefore contains a lot of code that (at the low level) looks like
this:
if ((x & 7) == 6)
when checking whether an object has type tag 6, say. On x86-64 gcc -O2
generates insns like this:
movq %rax, %rbx
andl $7, %ebx
cmpq $6, %rbx
whereas the following would be smaller and faster:
leal -6 (%rax), %ebx
tstl $7, %ebx
Doing this to a test version of Emacs made it 0.4% faster overall, on my
standard benchmark of Emacs byte-compiling all its Lisp files.
I'm attaching a source file fg.c that illustrates the problem. It defines a
function f that uses the Emacs idiom and is poorly optimized compared to the
equivalent function g. I also plan to attach the assembly language output fg.s,
which shows that f has one more instruction than g.
I plan to tune Emacs so that it cajoles GCC into the better insns; however, GCC
should optimize this code better, for the sake of programs other than Emacs.
