<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 30, 2014 at 7:34 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@azulsystems.com" target="_blank">sanjoy@azulsystems.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi!<br>
<div><br>
On May 30, 2014, at 5:12 PM, Vadim Chugunov <<a href="mailto:vadimcn@gmail.com" target="_blank">vadimcn@gmail.com</a>> wrote:<br>
<br>
> 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>
> 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>Does llvm actually emit code to directly access the callee saved registers?  As long as all llvm does is push them on entry and pop them on exit, you don't really care very much about offsets.<br>
<br>
As far as DWARF information is concerned, I'd expect the locations of the callee saved register spills be in terms of the CFA (Canonical Frame Address), and as long as llvm emits a correct expression to calculate the CFA at all points of the function body, DWARF readers should do fine.<br>


<br>
My initial point of confusion was that it seems llvm has some internal discrepancies about what slots CSRs get mapped to -- the actual code seems to push them in an different order than the they are assigned slots on the stack.  This gets corrected later on, and we do get accurate .cfi directives, so I figured that this may be some convention that I had missed.<br>


<br>
However, (thanks to Pasi's hint) there are cases where llvm generates incorrect .cfi directives, and this leads me to think that the issue is, in fact, the lack of co-ordination between the code that emits the PUSH instructions and the code that assigns stack slots to the CSR frame indices.<br>

</blockquote><div><br></div><div>If CSR indices corresponded to the actual locations where the registers are saved, it might be possible to use CSR info and getFrameIndexReference() to generate offsets for CFI directives, and everything would be in sync pretty much automatically, no?<br>

</div><div><br>Anyhow, I am interested in this because I am trying to implement SEH unwind info emission for 64 bit Windows.  Currently, the XMM registers are being spilled into non-fixed frame slots, and if the stack is realigned, they end up on the wrong side of the "realignment gap".   This makes generation of SEH info (which is far less expressive than DWARF CFI) very challenging.  Things would be much easier if XMMs were saved above the gap, and thus addressable via the base pointer.<br>

<br></div><div></div><div>Does anybody know if it is possible to assign callee-saved registers to fixed frame slots?   Any ideas about how to achieve that?    Would it be ok to simply re-write CSR info inside spillCalleeSavedRegisters()? <br>

<br></div><div>Vadim<br></div></div><br></div></div>