[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