<div dir="ltr"><div><div>Hi, <br>I have a related question. The spilled x86 GPRs are assigned positive frame indices, which seems problematic in cases when stack needs to be realigned: they are pushed before stack is re-aligned, so they cannot be addressed relative to the stack pointer (because there is a random gap caused by SP re-alignment).<br>
<br></div>Shouldn't they be assigned negative indices, i.e. be fixed objects, in which case they can be addressed relative to BP?<br><br></div>Vadim<br><div><div><br></div></div></div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Fri, May 30, 2014 at 4:48 PM, Pasi Parviainen <span dir="ltr"><<a href="mailto:pasi.parviainen@iki.fi" target="_blank">pasi.parviainen@iki.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 31.5.2014 2:04, Pasi Parviainen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 28.5.2014 2:57, Sanjoy Das wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi llvmdev,<br>
<br>
I'm trying to figure how llvm remembers stack slots allotted to callee<br>
saved registers on x86. In particular, llvm pushes registers in<br>
decreasing order of FrameIdxs [1], so the offsets they get (as<br>
returned by MFI->getObjectOffset) don't directly correspond to their<br>
actual stack locations. In X86FrameLowering's<br>
emitCalleeSavedFrameMoves, when emitting DWARF information, this<br>
discrepancy gets fixed up by subtracting the offset reported by<br>
MFI->getObjectOffset from the minimum offset for any CSR (this is done<br>
by the "Offset = MaxOffset - Offset + saveAreaOffset;" line). Is<br>
there a reason why llvm doesn't keep around the offsets in the right<br>
order from very beginning, by pushing the CSRs in increasing order of<br>
FrameIdxs?<br>
</blockquote>
<br>
Now, that you mention it, I remember being down to the same rabbit hole.<br>
With certain calling conventions (coldcc, I think it was which can for<br>
sure expose this for x86), it is possible to generate invalid CFI<br>
directives for the registers in a frame. Especially when XMM registers<br>
must be preserved along with general purpose registers. And the reason<br>
for this was the offset fixing logic within emitCalleeSavedFrameMoves,<br>
which breaks when fixing offset for XMM registers.<br>
<br>
To fix this disparity, I concluded that it could be done by reversing<br>
definition order of general purpose registers within X86CallingConv.td<br>
for all calling conventions, since llvm prefers to use push/pop model<br>
for storing GPR:s (for x86). With this change stack slots and registers<br>
would have 1:1 mapping, without extra offset calculations and<br>
emitCalleeSavedFrameMoves could be simplified by removing extra magic to<br>
determine slots, and to generate correct CFI directives in unusual cases.<br>
</blockquote>
<br></div></div>
Now that checking out some old experimental code to solve this, it also seems to require to reversing the order of XMM/YMM registers within calling convention definitions in X86CallingConv.td, and to do other minor changes to account for these.<div class="HOEnZb">
<div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[1]: in fact, the way X86FrameLowering's spillCalleeSavedRegisters and<br>
PEI's calculateCalleeSavedRegisters are set up, I don't see a reason<br>
why the FrameIdxs and the generated push instructions have any<br>
relation at all. It seems that the code relies on<br>
MFI->CreateStackObject returning sequential integers.<br>
<br>
Thanks!<br>
-- Sanjoy<br>
<br>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
<br>
</blockquote>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>