[PATCH] D15393: [X86] Order the local stack symbols to improve code size and locality.

[Zia Ansari via llvm-commits]

zansari marked 12 inline comments as done.
zansari added a comment.

Ping..

Also, another quick comment regarding minimizing stack frame size before my changes:

In addition to my comment/response above regarding stack frame size, I don't think that the existing symbol ordering heuristics minimizes frame size, in all cases... For example :

  int a;
  int c;
  int e;
  __attribute__((aligned(32))) int b;
  __attribute__((aligned(32))) int d;
  bar(&a, &b, &c, &d, &e);
  bar2(&a, &c, &e);

With -m32, the existing symbol table layout will require 128bytes for this frame. With my heuristics, we only require 96bytes.

The current layout will vary frame size depending on the order in which we DECLARE the variables, indicating that we don't do everything we can to ensure we minimize the frame size. My heuristics may not always find the smallest frame size, since it tends to favor code size a little over frame size, but it tends to be close and remain consistent, no matter what order the variables are declared. I don't think we can get a perfect frame-size vs code-size tradeoff, since we need to favor one over the other.


================
Comment at: lib/CodeGen/PrologEpilogInserter.cpp:708
@@ -707,1 +707,3 @@
 
+  std::vector<int> ObjectsToAllocate;
+
----------------
hans wrote:
> Maybe use SmallVector instead?
Correct me if I'm wrong, but doesn't SmallVector require a compile-time known size?

================
Comment at: lib/Target/X86/X86FrameLowering.cpp:2678
@@ +2677,3 @@
+  // indexing into it, instead of having to search for it every time.
+  std::vector<X86FrameSortingObject> SortingObjects(MFI->getObjectIndexEnd());
+
----------------
hans wrote:
> Maybe SmallVector?
Correct me if I'm wrong, but doesn't SmallVector require a compile-time known size?


http://reviews.llvm.org/D15393