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

[Reid Kleckner]

  Thanks!

  I decided not to do a split document.  I just put more text in LangRef.

  Speaking of design, I think this approach is better than the "bag-of-bytes" design suggested at the dev meeting.  Doing a single frame allocation would make calls look significantly different from their current form, and would confuse alias analysis, since you could GEP from one argument to another, while you can't do that with separate allocas.

  At this point I have follow on patches that implement mostly correct codegen for this, so I think the design is right, and I'd like to push this in, with some follow on transform stuff.  Any final design thoughts?


================
Comment at: test/Verifier/inalloca1.ll:10
@@ +9,2 @@
+declare void @d(void ()* inalloca %p)
+; CHECK: do not support unsized types
----------------
Meador Inge wrote:
> Some more tests for the other attribute incompatibilities and return value check would be nice.
Done

================
Comment at: lib/IR/Function.cpp:86
@@ -85,2 +85,3 @@
 }
 
+bool Argument::hasInAllocaAttr() const {
----------------
Meador Inge wrote:
> Minor nit, but most of the surrounding Argument:: queries in this file have header comments.
Sure.

================
Comment at: docs/LangRef.rst:713
@@ +712,3 @@
+    with ``byval``, ``readonly``, and others. These rules are enforced
+    by the verifier.
+
----------------
Meador Inge wrote:
> I don't see where 'readonly' is actually checked in the verifier.  Also, the last sentence makes it sound like the "must be an alloca" and "must be used at most once" constraints are checked as well, but I don't see where.
Woops, that was missing from the diff.

================
Comment at: docs/LangRef.rst:716
@@ +715,3 @@
+    Any use of ``inalloca`` arguments must comply with the target's ABI.
+    ``inalloca`` cannot be applied to parameters are passed in
+    registers, and the allocas must be executed in the order in which
----------------
Meador Inge wrote:
> "... that are passed ..."?
fixed


http://llvm-reviews.chandlerc.com/D2173