<div dir="ltr">On Tue, Jul 30, 2013 at 11:07 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How do you handle this during codegen? One problem is avoid stack<br>
changes (like spills)</blockquote><div><br></div><div>I'm not sure I understand your question, but my plan is to basically use a frame pointer when there is a call with an argument using the 'alloca' attribute.  It'll be slow but functional.</div>
<div><br></div><div>Later the backend can be optimized to be clever about spilling through an SP-based memory operand in the presence of stack adjustments.  I don't yet have a concrete plan for this, and it will require more familiarity with the backend than I currently have.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Another is coordinating things that are using<br>
allocas and those that are not but end up in the stack. Consider<br>
<br>
void foo(int arg1, int arg2, int arg3, ....CXXTypeWithCopyConstructor<br>
argn, int argp1...)<br>
<br>
You will need an alloca for argn, but the ABI also requires it to be<br>
next to the plain integers that didn' fit in registers, no? This is<br>
part of the reason my suggestion was to have a single opaque object<br>
representing the frame being constructed and a getelementpointer like<br>
abstraction to get pointers out of it.</blockquote><div><br></div><div>This proposal puts this complexity in the backend.  The backend will lay out the outgoing argument slots as required by the ABI, and alloca pointer will be resolved to point to the appropriate outgoing argument slot.</div>
<div><br></div><div>The verifier will be changed to reject IR with a live alloca between a call site with an alloca-attributed argument and the creation of that alloca.</div><div><br></div><div>This will work however:</div>
<div><br></div><div>%s1 = stacksave</div><div>%1 = alloca stackbase %s1</div><div>%s2 = stacksave</div><div>%2 = alloca stackbase %s2</div><div>call @foo(%2 alloca)</div><div>stackrestore %s2</div><div>call @foo(%1 alloca)</div>
<div>stackrestore %s1</div><div><br></div><div>Because the %2 alloca is dead due to the stack restore before the second foo call.</div><div><br></div><div>I should also mention how this interacts with regparms.   The win64 CC has 4 regparms, and if one of them is a struct, it is passed indirectly.  Users can easily handle that in the frontend, and the backend could reject the alloca attribute on parameters that should be in registers.  I need to double-check what happens for fastcall on x86_32.</div>
</div></div></div>