[PATCH] D14147: Hanlding of aligned allocas on a target that does not align stack pointer.

hfinkel@anl.gov via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 26 08:18:30 PST 2015


hfinkel accepted this revision.
hfinkel added a reviewer: hfinkel.
hfinkel added a comment.
This revision is now accepted and ready to land.

LGTM.


================
Comment at: include/llvm/CodeGen/MachineFrameInfo.h:128
@@ -127,1 +127,3 @@
   /// Can the stack be realigned.
+  /// Targets that set this to false have to handle alignment of all
+  /// allocas themselves, i.e. while lowering DYNAMIC_STACKALLOC
----------------
  /// Targets that set this to false don't have the ability to overalign
  /// their stack frame, and thus, overaligned allocas are all treated
  /// as dynamic allocations and the target must handle them as part
  /// of DYNAMIC_STACKALLOC lowering.
  /// FIXME: There is room for improvement in this case, in terms of
  /// grouping overaligned allocas into a "secondary stack frame" and
  /// then only use a single alloca to allocate this frame and only a
  /// single virtual register to access it. Currently, without such an
  /// optimization, each such alloca gets it's own dynamic
  /// realignment.

================
Comment at: lib/CodeGen/SelectionDAG/FunctionLoweringInfo.cpp:118
@@ -108,3 +117,3 @@
+            (TFI->isStackRealignable() || (Align <= StackAlign))) {
           const ConstantInt *CUI = cast<ConstantInt>(AI->getArraySize());
           uint64_t TySize = MF->getDataLayout().getTypeAllocSize(Ty);
----------------
Add:

  // FIXME: Overaligned static allocas should be grouped into a single dynamic allocation instead of using a separate stack allocation for each one.


http://reviews.llvm.org/D14147





More information about the llvm-commits mailing list