[llvm-bugs] [Bug 24448] New: [x86] avoid big bad immediates in the instruction stream, part 2: hoist constants
via llvm-bugs
llvm-bugs at lists.llvm.org
Thu Aug 13 11:19:26 PDT 2015
https://llvm.org/bugs/show_bug.cgi?id=24448
Bug ID: 24448
Summary: [x86] avoid big bad immediates in the instruction
stream, part 2: hoist constants
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedbugs at nondot.org
Reporter: spatel+llvm at rotateright.com
CC: llvm-bugs at lists.llvm.org
Classification: Unclassified
This report is based on the post-commit thread for r244601:
http://reviews.llvm.org/rL244601
http://reviews.llvm.org/D11363
Sean Silva observed sequences of 11-byte (!) instructions:
20b7f: 48 c7 80 78 01 00 00 00 00 00 00 movq $0, 376(%rax)
20b8a: 48 c7 80 80 01 00 00 00 00 00 00 movq $0, 384(%rax)
20b95: 48 c7 80 88 01 00 00 00 00 00 00 movq $0, 392(%rax)
...
One way to reduce this bloat - hoist a repeated constant into a register:
xorl %ebx, %ebx [31 db]
movq %rbx, 376(%rax) [48 89 98 78 01 00 00]
movq %rbx, 384(%rax) [48 89 98 80 01 00 00]
movq %rbx, 392(%rax) [48 89 98 88 01 00 00]
...that's 23 bytes instead of 33.
The size savings formula for enabling this optimization for 32-bit immediates
is:
+5 bytes for the extra movl (or +2 bytes for the special case of xor zero)
-4 bytes for removing the 32-bit immediate from each instruction
So in general, if (5 - 4*N) < 0, do it:
N > 1
We can do this to save size anytime we have at least 2 instructions that store
the same 32-bit immediate. If the constant is zero, always do it!
The hope is that this transform also improves *performance* for all recent
chips despite increasing the official instruction count. The key to make that
generalization is that storing immediates is actually more expensive than
storing a register.
Immediate stores may be implemented micro-architecturally using 2 uops rather
than 1 uop (see AMD SOG for Jaguar), and/or repeated 32-bit immediates cause a
uop cache to lose effectiveness (see Intel Optimization Manual rules 38 and
39).
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150813/54d3174d/attachment.html>
More information about the llvm-bugs
mailing list