[CGCall] Mapping elements of CallArgList to parameter declarations

Hi,

I need to access declarations of function parameters when I emit a call to this function. Namely, if certain function parameters are declared to be nonnull (by attribute((nonnull))), I can add corresponding attributes to the call site and emit a runtime check verifying that call arguments are indeed nonnull.

This turns out to be unexpectedly hard: when we emit a call (CodeGenFunction::EmitCall), we have the following information:

  1. CGFunctionInfo, which is essentially a vector describing types/ABI kinds of call arguments (of LLVM IR function).
  2. CallArgList, which has the same size as CGFunctionInfo and contains RValues - actual call arguments.
  3. (optional) Decl of a callee.
    However, we don’t have a mapping that would tell us which elements of CGFunctionInfo/CallArgList correspond to ParmVarDecl in a callee Decl (there can be different kinds of implicit arguments, like “this”, or VTT, and their position in CallArgList is not trivially deducible).

Am I missing something obvious? Or this task indeed can’t be done without significant refactoring of CGCall logic? Thanks.

I just thought of something. Try threading the function or block decl through EmitCallArgs. EmitCallArgs is responsible for evaluating all user-written Exprs, which should have a one-to-one correspondence with ParmVarDecls on the function or block decl.

Thanks for suggestion! This might indeed work for emitting a runtime checks of the call arguments but wouldn’t help with setting a comprehensive set of attributes on the IR function call (we currently construct this attribute set at the very last stage, right before building the actual call/invoke instruction).

While we’re here, I noticed that there is another kind of nontrivial mapping, which maps the elements of CallArgList/CGFunctionInfo to IR function arguments (it’s not 1:1, e.g. if we have “Expand” ABIKind one item from CallArgList is passed in several arguments). The logic for building this mapping (with all its complexities like checking if “sret” should be swapped with “this”) is copied three times - in EmitCall, EmitFunctionPrologue and in ConstructAttributeList. Do you think the code will benefit from factoring it out?

Thanks for suggestion! This might indeed work for emitting a runtime
checks of the call arguments but wouldn't help with setting a comprehensive
set of attributes on the IR function call (we currently construct this
attribute set at the very last stage, right before building the actual
call/invoke instruction).

Sadly enough, we also won't be able to set necessary nonnull attributes on
the function declaration. Still, I'll try to work on at least setting the
attributes at the call site.

While we're here, I noticed that there is another kind of nontrivial
mapping, which maps the elements of CallArgList/CGFunctionInfo to IR
function arguments (it's not 1:1, e.g. if we have "Expand" ABIKind one item
from CallArgList is passed in several arguments). The logic for building
this mapping (with all its complexities like checking if "sret" should be
swapped with "this") is copied three times - in EmitCall,
EmitFunctionPrologue and in ConstructAttributeList. Do you think the code
will benefit from factoring it out?

http://reviews.llvm.org/D4938. Sorry.