[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