[cfe-dev] [CGCall] Mapping elements of CallArgList to parameter declarations

[Alexey Samsonov]

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?


On Thu, Aug 14, 2014 at 11:43 AM, Reid Kleckner <rnk at google.com> wrote:

> 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.
>
>
> On Thu, Aug 14, 2014 at 11:26 AM, Alexey Samsonov <vonosmas at gmail.com>
> wrote:
>
>> 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.
>>
>> --
>> Alexey Samsonov
>> vonosmas at gmail.com
>>
>
>


-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140814/ffd930a8/attachment.html>