The back-story here is that PEI tries to keep track of how much starting or ending a call sequence adjusts the stack pointer, so that it can resolve frame-index references.
Currently, it takes a very simplistic view of how SP adjustments are done - both FrameStartOpcode and FrameDestroyOpcode adjust it exactly by the amount written in its first argument.
This is in fact false for many targets (e.g. due to stack re-alignment, or because it may want to adjust the stack pointer in multiple steps).
So why don't things break? Because most targets (the only in-tree exception I could find is 32-bit ARM) rely on being able to simplify the call frame pseudo-instructions earlier, so this code is never hit. This assumption is enforced by an "assert(SPAdj == 0 && "Unexpected")" in eliminateFrameIndex().
I want to start using it on x86 (to make the mov -> push transform work, http://reviews.llvm.org/D6789 will depend on this), and that means delegating the decision to the target, so that x86 can return the actual adjustment value.
don't repeat the name in the comment.