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

[Alexey Samsonov]

On Thu, Aug 14, 2014 at 1:45 PM, Alexey Samsonov <vonosmas at gmail.com> wrote:

> 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.


>
>
> 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
>



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