<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Aug 30, 2015 at 6:09 PM, Joseph Tremoulet via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>  If someone has another approach, I'm also very open to that.<br>
<br>
</span>I recently saw another compiler use a "cute trick" for this sort of thing: allocate a fixed amount of space on the stack by including the worst-case padding, and then dynamically set the frame pointer to an aligned location within that.  I wouldn't go so far as to say that's a *better* approach (it seems gimmicky/fishy and could open other problems by surprising your runtime/tools in other ways), but it's certainly *another* one :).  The only actual benefit that comes to mind is that it would cover other sources of dynamic alignment than RA spill slots, if that's something you need to worry about.<br></blockquote><div><br></div><div>I came here to suggest this approach also. :)</div><div><br></div><div>Right now the X86 backend is using a stack realignment prologue that is designed to fixup the incoming and outgoing alignment to some number. We only need this prologue when the user is telling us that the incoming alignment is too low, and it must be fixed up (i.e. -mstackrealign).</div></div></div></div>