This is an archive of the discontinued LLVM Phabricator instance.

[CodeGen] Provide an appropriate alignment for dynamic allocas
ClosedPublic

Authored by majnemer on Sep 8 2016, 11:57 PM.

Details

Summary

GCC documents builtin_alloca as aligning the storage to at least
BIGGEST_ALIGNMENT__.

MSVC documents essentially the same for the x64 ABI:
https://msdn.microsoft.com/en-us/library/x9sx5da1.aspx

The 32-bit ABI follows the same rule: it emits a call to _alloca_probe_16

Diff Detail

Repository
rL LLVM

Event Timeline

majnemer updated this revision to Diff 70789.Sep 8 2016, 11:57 PM
majnemer retitled this revision from to [CodeGen] Provide an appropriate alignment for dynamic allocas.
majnemer updated this object.
majnemer added reviewers: rnk, rsmith, efriedma, chandlerc.
majnemer added a subscriber: cfe-commits.
rnk accepted this revision.Sep 9 2016, 8:30 AM
rnk edited edge metadata.

lgtm

This revision is now accepted and ready to land.Sep 9 2016, 8:30 AM
efriedma edited edge metadata.Sep 9 2016, 10:13 AM

This is probably going to lead to someone complaining about clang realigning the stack on 32-bit Windows; are your sure we're choosing the right alignment there?

rnk added a comment.Sep 9 2016, 11:18 AM

This is probably going to lead to someone complaining about clang realigning the stack on 32-bit Windows; are your sure we're choosing the right alignment there?

I checked, and MSVC emits a call to __alloca_probe_16 for this code:

extern "C" void *_alloca(size_t);
#pragma intrinsic (_alloca)
void g(void*);
void f(int n) {
  void *p = _alloca(n);
  g(p);
}

So, they do realign the stack. We don't really need to realign the whole stack frame for highly aligned dynamic allocas, though. There's no reason we can't overallocate from the stack and realign the returned pointer. I'm not sure if we do that, though...

Huh... then I guess this is fine.

This revision was automatically updated to reflect the committed changes.