<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 14, 2014 at 1:45 PM, Alexey Samsonov <span dir="ltr"><<a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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).</div>
</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>
<br></div><div>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?</div>
</div></blockquote><div><br></div><div><a href="http://reviews.llvm.org/D4938">http://reviews.llvm.org/D4938</a>. Sorry.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
</div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Thu, Aug 14, 2014 at 11:43 AM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">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.</div>

<div><div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 14, 2014 at 11:26 AM, Alexey Samsonov <span dir="ltr"><<a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>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.</div>



<div><br></div><div>This turns out to be unexpectedly hard: when we emit a call (CodeGenFunction::EmitCall), we have the following information:</div><div>  1) CGFunctionInfo, which is essentially a vector describing types/ABI kinds of call arguments (of LLVM IR function).</div>



<div>  2) CallArgList, which has the same size as CGFunctionInfo and contains RValues - actual call arguments.</div><div>  3) (optional) Decl of a callee.</div><div>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).</div>



<div><br></div><div>Am I missing something obvious? Or this task indeed can't be done without significant refactoring of CGCall logic? Thanks.</div><span><font color="#888888"><div><div><br></div>-- <br>
<div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div>

</div></font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class=""><font color="#888888">-- <br><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div>

</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div>
</div></div>