[PATCH] [X86] A first stab at a heuristic to estimate the size impact for converting movs to pushes

Reid Kleckner rnk at google.com
Wed Feb 11 14:00:23 PST 2015


lgtm


================
Comment at: lib/Target/X86/X86CallFrameOptimization.cpp:193-195
@@ +192,5 @@
+    } else {
+      // We can use pushes. First, account for the fixed costs.
+      // We'll need a add after the call.
+      Advantage -= 3;
+      // If we have to realign the stack, we'll also need and sub before
----------------
Not if the calling convention is callee-pop. In fact, if the convention is callee-pop, using a reserved call frame requires a sub, which should give the 'mov' lowering a penalty.

Anyway, not a blocking issue, just a heuristic worth adding.

================
Comment at: lib/Target/X86/X86CallFrameOptimization.cpp:199
@@ +198,3 @@
+        Advantage -= 3;
+      // Now, for each push, we save ~3 bytes. For small constants, we actually,
+      // save more (up to 5 bytes), but 3 should be a good approximation.
----------------
Can we motivate the 3 byte saving heuristic a bit more?

================
Comment at: test/CodeGen/X86/movtopush.ll:298-299
@@ +297,4 @@
+; NORMAL-NEXT: movl    $1, (%esp)
+; NORMAL-NEXT: movl    $2, %eax
+; NORMAL-NEXT: calll _inreg
+; NORMAL-NEXT: movl    $8, 12(%esp)
----------------
I'd really like to be able to convert to pushes for __thiscall methods, which effectively have one inreg parameter.

http://reviews.llvm.org/D7561

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list