This is an archive of the discontinued LLVM Phabricator instance.

CGCall: Factor out the logic mapping call arguments to LLVM IR arguments.
ClosedPublic

Authored by samsonov on Aug 15 2014, 3:05 PM.

Details

Summary

This refactoring introduces ClangToLLVMArgMapping class, which
encapsulates the information about the order in which function arguments listed
in CGFunctionInfo should be passed to actual LLVM IR function, such as:

  1. positions of sret, if there is any
  2. position of inalloca argument, if there is any
  3. position of helper padding argument for each call argument
  4. positions of regular argument (there can be many if it's expanded).

Simplify several related methods (ConstructAttributeList, EmitFunctionProlog
and EmitCall): now they don't have to maintain iterators over the list
of LLVM IR function arguments, dealing with all the sret/inalloca/this complexities,
and just use expected positions of LLVM IR arguments stored in ClangToLLVMArgMapping.

This may increase the running time of EmitFunctionProlog, as we have to traverse
expandable arguments twice, but in further refactoring we will be able
to speed up EmitCall by passing already calculated CallArgsToIRArgsMapping to
ConstructAttributeList, thus avoiding traversing expandable argument there.

No functionality change.

Diff Detail

Event Timeline

samsonov updated this revision to Diff 12574.Aug 15 2014, 3:05 PM
samsonov retitled this revision from to CGCall: Factor out the logic mapping call arguments to LLVM IR arguments..
samsonov updated this object.
samsonov edited the test plan for this revision. (Show Details)
samsonov added a reviewer: rnk.
samsonov added subscribers: timurrrr, rjmccall, Unknown Object (MLST).
rnk edited edge metadata.Aug 15 2014, 3:46 PM

Nice! I've contemplated doing a cleanup like this, but it looks like you have succeeded where I have failed.

lib/CodeGen/CGCall.cpp
1044

I think we can sink all of this into CGFunctionInfo once we remove the AAPCS issue. I pinged James Molloy about this.

1136

Maybe we can do this once after computing CGFunctionInfo and then store it in CGFunctionInfo?

samsonov added inline comments.Aug 18 2014, 10:59 PM
lib/CodeGen/CGCall.cpp
1044

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.

1136

See comment above. We might, though, have a different cache that would tell the number of IR arguments each QualType will extend to.

rnk added a reviewer: rsmith.Aug 21 2014, 11:46 AM
rnk edited reviewers, added: majnemer; removed: rsmith.
rnk added a comment.Aug 21 2014, 12:01 PM

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

lib/CodeGen/CGCall.cpp
1044

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?

1050

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.

1088

'construct' is pretty big, I'd pull it out of line to reduce indentation.

1144–1146

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?

samsonov added inline comments.Aug 21 2014, 1:47 PM
lib/CodeGen/CGCall.cpp
1144–1146

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?

rnk added inline comments.Aug 21 2014, 3:10 PM
lib/CodeGen/CGCall.cpp
1144–1146

Yeah, sounds good.

samsonov added inline comments.Aug 21 2014, 4:52 PM
lib/CodeGen/CGCall.cpp
1044

Done

1050

Got rid of this in favor of vector of triples.

1088

Done

1144–1146

Done

samsonov updated this revision to Diff 12815.Aug 21 2014, 4:52 PM

Address reviewer's comments.

rnk accepted this revision.Aug 21 2014, 6:00 PM
rnk edited edge metadata.

lgtm

This revision is now accepted and ready to land.Aug 21 2014, 6:00 PM
samsonov updated this revision to Diff 12822.Aug 21 2014, 6:13 PM
samsonov edited edge metadata.

Rebase.

samsonov updated this object.Aug 21 2014, 6:14 PM
samsonov closed this revision.Aug 21 2014, 6:15 PM