================
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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
