<div>On Mon, Oct 22, 2012 at 5:49 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:</div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> In trunk, the frame pointer is always set up when an AVX register is used in<br>
> a function. This is done in case 32-byte spill code is later introduced into<br>
> the function and hence dynamic stack realignment is needed. Needless to say,<br>
> it's a big hammer. This regression seems particularly painful in<br>
> small-to-medium sized routines that are called frequently in some codes.<br>
><br>
><br>
> Is this issue already known? Is there a plan to fix this regression? If not,<br>
> does anyone have a suggestion on the best way to remedy this issue?<br>
><br>
<br>
</div>You'd need to change the default stack alignment of the platform to<br>
deal with it effectively.</blockquote><div><br></div><div>Hey Eric, </div><div><br></div><div>Thanks for replying so quickly. Would you elaborate on this further?</div><div><br></div><div>It seems costly to change the default stack alignment on the platform, since that would require recompiling all of the system and user libraries to also adhere to 32-byte stack alignment. Depending on an alignment not specified by the ABI would also limit our compiler's interoperability with other compilers installed on the system.</div>
<div><br></div><div>I suppose that the stack could be aligned dynamically at main(...) and other visible entry points, but that too seems costly compared to the current M.O..</div><div><br></div><div>Maybe I do not fully understand all the issues involved, but I suppose I should be able to dynamically align the stack only when AVX registers are spilled in a function, right? Seems reasonable with my limited knowledge. Do you have any intuition built? It could be possible that the prologue/epilogue emitters run prior to the spilling decisions. I am not so sure of the ordering here.</div>
<div><br></div><div>Also, and this might be asking a lot, but do you have any insight into why this behaviour changed sometime around the LLVM 3.0 release? I have not been able to find much history.</div><div><br></div><div>
Thanks again,</div><div>Cameron</div></div></div>