[PATCH] CGCall: Factor out the logic mapping call arguments to LLVM IR arguments.

[Reid Kleckner]

+David Majnemer, since he had opinions about doing sret/this the Right Way.

================
Comment at: lib/CodeGen/CGCall.cpp:1048
@@ +1047,3 @@
+
+class CallArgsToIRArgsMapping {
+  const unsigned InvalidIndex = ~0U;
----------------
Alexey Samsonov wrote:
> Reid Kleckner wrote:
> > I think we can sink all of this into CGFunctionInfo once we remove the AAPCS issue.  I pinged James Molloy about this.
> I thought that CGFunctionInfo is designed to be as small as possible (all of them are memoized in CodeGenTypes, for instance), and Args->IRArgs mapping in fact describes the "algorithm", not a function definition and would hardly be useful outside if CGCall routines.
Well, previously Mark Lacey was trying to teach LLDB about these kinds of things, so I thought it might be useful to hoist out. However, it looks like that effort was abandoned, so let's keep this here until we hear otherwise.

Can we name this better? Maybe ClangToLLVMArgMapping or ASTToIRArgMapping? Or just IRArgMapping?

================
Comment at: lib/CodeGen/CGCall.cpp:1054
@@ +1053,3 @@
+  SmallVector<unsigned, 4> PaddingIRArgIndex;
+  SmallVector<SmallVector<unsigned, 1>, 4> IRArgs;
+
----------------
99% of the time the inner SmallVector will have size 1. This basically what TinyPtrVector is for, but I guess we can't use that to store unsigned ints. Hm.

================
Comment at: lib/CodeGen/CGCall.cpp:1092
@@ +1091,3 @@
+private:
+  void construct(CodeGenModule &CGM, const CGFunctionInfo &FI) {
+    unsigned IRArgNo = 0;
----------------
'construct' is pretty big, I'd pull it out of line to reduce indentation.

================
Comment at: lib/CodeGen/CGCall.cpp:1148-1150
@@ +1147,5 @@
+
+      for (; NumIRArgs > 0; --NumIRArgs) {
+        IRArgs[ArgNo].push_back(IRArgNo++);
+      }
+
----------------
Looks like all argument types consume either zero, one, or sequential IR arguments.  This only needs to store one number per AST-level argument. If there are zero IR args, use InvalidIndex. If there is one IR arg, store the IR arg number. If there are more than one, store the first IR arg number. The consumers can increment that during argument expansion.

Does that sound reasonable?

http://reviews.llvm.org/D4938