[PATCH] D11377: x86: check hasOpaqueSPAdjustment in canRealignStack

Reid Kleckner rnk at google.com
Wed Jul 22 09:45:13 PDT 2015

rnk added a comment.

Right, your test case is essentially

To get into a case where `canRealignStack` matters, I think you need:

- No dynamic alloca (otherwise we short-circuit out due to


- No highly-aligned alloca (otherwise we commit to stack realignment early)
- A highly-aligned SSA value (a vector) that must be spilled during

register allocation (is live across a call)

If that doesn't do it, then I think this code is dynamically dead, at least
for now. =/

My understanding is that the original purpose of canRealignStack was to
figure out, part way through register allocation, if the aligned or
unaligned vector load and store instructions should be used to spill to the
stack. In some circumstances, ESI may have already been reserved by inline
asm, a custom calling convention, or something else, so we needed this
check. I think Anton added it as part of

Then, at some point, someone decided that realigning the stack was too
expensive, since even if you don't have dynamic allocas, it burns EBP,
wasting a precious x86 GPR. I can't find the PRs or revisions for this, but
I think Chad Rosier tweaked the x86 backend so that it doesn't try to
realign the stack anymore. Instead it just uses the unaligned vector loads
and stores.

So, it sounds like this change is untestable, but I feel like we should
throw it in there, because this condition should really be identical to
CantUseSP in hasBasePointer.


More information about the llvm-commits mailing list