[PATCH] D11363: Allow merging of immediates within a basic block for code size savings and reduced footprint.

Zia Ansari zia.ansari at intel.com
Mon Jul 20 12:29:14 PDT 2015

zansari created this revision.
zansari added reviewers: mkuper, qcolombet, spatel, nadav.
zansari added a subscriber: llvm-commits.

First attempt / phase of changes to prevent common immediates that occur more than once within a single basic block to be pulled into their users, in order to prevent unnecessary large instruction encoding.

A quick run on cpu2k shows just over 1% .text size savings on the sum of all the objects (around 8% on just 252.eon alone). Performance (O2 and Os) is flat, though this is currently only enabled under Os, with the hopes to later also include O2.

This is a first attempt and phase of this, with later followup including:
1) Increase the instruction types of users beyond stores and binary ops.
2) Enable at O2.
3) Move beyond single BB to operate globally in a function.

These other phases will require a little additional work to be done to make them safe.

Included is a request to delete CodeGen/X86/remat-invalid-liveness.ll

Justification : This is a large test that failed at some point due to a register being incorrectly clobbered. It was trimmed down a little to allow for a regression test. The CHECK conditions loosely resembled the original failing condition, and now look like this:
   ; CHECK: movl $3, %ecx
   ; CHECK-NOT: subb %{{[a-z]+}}, %ch

Note that (1) There are a few instances of "movl $3, %ecx", and (2) there's a lot of code between the different movs and the subb.
Based on those to conditions, it's extremely hard (without some form of data flow analysis) to determine that the "subb" is, indeed, bad. For example, with my changes, I get:
                                        movl              $3, %ecx
                                        movb            $64, %ch
                                        testb             %cl, %al
                                        subb              %al, %ch
..which is reasonable, yet fails.

I can't think of any reasonable way to fix this test to catch the intended issue.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: D11363.30173.patch
Type: text/x-patch
Size: 13390 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150720/547c0fe0/attachment.bin>

More information about the llvm-commits mailing list