[llvm] r197645 - Begin adding docs and IR-level support for the inalloca attribute

[Chris Lattner]

On Dec 18, 2013, at 6:14 PM, Reid Kleckner <reid at kleckner.net> wrote:
> The inalloca attribute is designed to support passing C++ objects by
> value in the Microsoft C++ ABI.  It behaves the same as byval, except
> that it always implies that the argument is in memory and that the bytes
> are never copied.  This attribute allows the caller to take the address
> of an outgoing argument's memory and execute arbitrary code to store
> into it.

I'm glad you're working on this, I'm a big fan of your project to get MSVC ABI compatibility.

> 
> +The :ref:`attr_inalloca` attribute is designed to allow taking the
> +address of an aggregate argument that is being passed by value through
> +memory.  Primarily, this feature is required for compatibility with the
> +Microsoft C++ ABI.  Under that ABI, class instances that are passed by
> +value are constructed directly into argument stack memory.  Prior to the
> +addition of inalloca, calls in LLVM were indivisible instructions.
> +There was no way to perform intermediate work, such as object
> +construction, between the first stack adjustment and the final control
> +transfer.  With inalloca, each argument is modelled as an alloca, which
> +can be stored to independently of the call.  Unfortunately, this
> +complicated feature comes with a large set of restrictions designed to
> +bound the lifetime of the argument memory around the call, which are
> +explained in this document.
> +

I'm deeply concerned about this design, since this effectively breaks value semantic guarantees for LLVM IR by requiring that the immediate argument be an alloca.

It is a deeply held truth that  values are in SSA registers, and that any operation that doesn't affect the value can be done to the register.  Noop bitcasts can be inserted, stores and reloads to memory (e.g. the reg to stack pass), passing values as arguments to functions and returning them (for example, the code extraction pass), inserting PHI nodes when commoning code, are all examples of this.

I don't think that this is a good tradeoff in terms of compiler complexity to throw all of these guarantees out of the window for this.

-Chris