[LLVMdev] Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

[Reid Kleckner]

On Tue, Jul 30, 2013 at 11:07 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> How do you handle this during codegen? One problem is avoid stack
> changes (like spills)


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.

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.

Another is coordinating things that are using
> allocas and those that are not but end up in the stack. Consider
>
> void foo(int arg1, int arg2, int arg3, ....CXXTypeWithCopyConstructor
> argn, int argp1...)
>
> You will need an alloca for argn, but the ABI also requires it to be
> next to the plain integers that didn' fit in registers, no? This is
> part of the reason my suggestion was to have a single opaque object
> representing the frame being constructed and a getelementpointer like
> abstraction to get pointers out of it.


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.

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.

This will work however:

%s1 = stacksave
%1 = alloca stackbase %s1
%s2 = stacksave
%2 = alloca stackbase %s2
call @foo(%2 alloca)
stackrestore %s2
call @foo(%1 alloca)
stackrestore %s1

Because the %2 alloca is dead due to the stack restore before the second
foo call.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130730/d53f210c/attachment.html>