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

[Alexey Samsonov]

================
Comment at: lib/CodeGen/CGCall.cpp:1048
@@ +1047,3 @@
+
+class CallArgsToIRArgsMapping {
+  const unsigned InvalidIndex = ~0U;
----------------
Reid Kleckner wrote:
> 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?
Done

================
Comment at: lib/CodeGen/CGCall.cpp:1054
@@ +1053,3 @@
+  SmallVector<unsigned, 4> PaddingIRArgIndex;
+  SmallVector<SmallVector<unsigned, 1>, 4> IRArgs;
+
----------------
Reid Kleckner wrote:
> 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.
Got rid of this in favor of vector of triples.

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

================
Comment at: lib/CodeGen/CGCall.cpp:1148-1150
@@ +1147,5 @@
+
+      for (; NumIRArgs > 0; --NumIRArgs) {
+        IRArgs[ArgNo].push_back(IRArgNo++);
+      }
+
----------------
Reid Kleckner wrote:
> Alexey Samsonov wrote:
> > Reid Kleckner wrote:
> > > 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?
> > Yes, I think the assumption that all IR arguments are sequential is reasonable. Currently, we would still need to do argument expansion both here, and in EmitPrologue/EmitCall methods. I think it makes to store the number of expanded arguments to assert that the numbers match (at least until we refactor terribly similar GetExpandedTypes / ExpandTypeFromArgs / ExpandTypeToArgs into a single routine and/or introduce a map "QualType -> number of arguments it expands to").
> > 
> > What we can do is replace PaddingIRArgIndex and IRArgs vectors with a single vector of triples <PaddingIRArgIndex, FirstIRArgIndex, NumberOfIRArgs>. WDYT?
> Yeah, sounds good.
Done

http://reviews.llvm.org/D4938