<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">CallFrameSetupOpcode is a pseudo opcode like <span style="font-family: Menlo; font-size: 11px; color: rgb(52, 162, 161);">X86</span><span style="font-family: Menlo; font-size: 11px;">::ADJCALLSTACKDOWN64. That means when the code is expected to be called before the pseudo instructions are eliminated. I don't know why it's not the case for you. A quick look at PEI code indicates the pseudo's should not have been removed at the time when replaceFrameIndices are run.</span><div><font face="Menlo"><span style="font-size: 11px;"><br></span></font></div><div><font face="Menlo"><span style="font-size: 11px;">Evan</span></font></div><div><font face="Menlo"><span style="font-size: 11px;"><br></span></font><div><font face="Menlo"><span style="font-size: 11px;"><br></span></font><div><div>On Sep 25, 2013, at 8:57 AM, Krzysztof Parzyszek <<a href="mailto:kparzysz@codeaurora.org">kparzysz@codeaurora.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Hi All,<br>I'm dealing with a problem where the spill/restore instructions inserted during scavenging span an adjustment of the SP/FP register. The result is that despite the base register (SP/FP) being changed between the spill and the restore, both store and load use the same immediate offset.<br><br>I see code in the PEI (replaceFrameIndices) that is supposed to track the SP/FP adjustment:<br><br>----------------------------------------<br>void PEI::replaceFrameIndices(MachineBasicBlock *BB,<br> MachineFunction &Fn, int &SPAdj) {<br> const TargetMachine &TM = Fn.getTarget();<br> assert(TM.getRegisterInfo() &&<br> "TM::getRegisterInfo() must be implemented!");<br> const TargetInstrInfo &TII = *Fn.getTarget().getInstrInfo();<br> const TargetRegisterInfo &TRI = *TM.getRegisterInfo();<br> const TargetFrameLowering *TFI = TM.getFrameLowering();<br> bool StackGrowsDown =<br> TFI->getStackGrowthDirection() ==<br> TargetFrameLowering::StackGrowsDown;<br> int FrameSetupOpcode = TII.getCallFrameSetupOpcode();<br> int FrameDestroyOpcode = TII.getCallFrameDestroyOpcode();<br><br> if (RS && !FrameIndexVirtualScavenging) RS->enterBasicBlock(BB);<br><br> for (MachineBasicBlock::iterator I = BB->begin(); I != BB->end(); ) {<br><br> if (I->getOpcode() == FrameSetupOpcode ||<br> I->getOpcode() == FrameDestroyOpcode) {<br> // Remember how much SP has been adjusted to create the call<br> // frame.<br> int Size = I->getOperand(0).getImm();<br><br> if ((!StackGrowsDown && I->getOpcode() == FrameSetupOpcode) ||<br> (StackGrowsDown && I->getOpcode() == FrameDestroyOpcode))<br> Size = -Size;<br><br> SPAdj += Size;<br><br> [...]<br>----------------------------------------<br><br><br>The problem is that it expects frame-setup and frame-destroy opcodes, but at the time it runs (after emitPrologue/emitEpilogue) the frame setup and teardown will be expanded into instruction sequences that can be different for each target, let alone having the immediate value in the 0-th operand.<br><br>As I see, this code won't work, although I'm not sure what was the original idea behind it. Should this code run before the target specific generation of prolog/epilog? Even then, there won't need to be ADJCALLSTACKUP/DOWN instructions (if it's a leaf function). If it runs where it should, should it instead use some target-specific hook that identifies the actual stack adjustment amount?<br><br>-Krzysztof<br><br><br>--<span class="Apple-converted-space"> </span><br>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation<br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a><span class="Apple-converted-space"> </span> <a href="http://llvm.cs.uiuc.edu/">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></div></blockquote></div><br></div></div></body></html>