<p dir="ltr"><br>
On Jan 4, 2015 5:37 PM, "Philip Reames" <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>> wrote:<br>
><br>
> Did you intend to reply only to me on this?</p>
<p dir="ltr">Oops.</p>
<p dir="ltr">> On 01/04/2015 03:46 PM, Reid Kleckner wrote:<br>
>><br>
>> Maybe we can say that casting the arguments should work, or else UB. Note that we've had problems here in the past with byval.<br>
><br>
> I'm not quite sure what you meant by this.  Can you clarify specifically what "should work" means?</p>
<p dir="ltr">Just that bitcasting the caller arg types to the callee's parameter types and removing the indirect call should be semantically equivalent.</p>
<p dir="ltr">>> For that matter, it'd be good to understand if this call by itself is UB, or if similarly casting an i32 to float this way is valid.<br>
><br>
> It is definitely legal to express such a cast in the IR.  Are you suggesting that the cast should be of the argument, not of the function pointer type?  Disallowing function pointer casts would break a lot of idiomatic C code.  (I'm purposely not making any claim about the UB vs non-UB nature of such idiomatic code.)</p>
<p dir="ltr">By "valid" I just mean "has defined behavior". I'm pretty sure C says that regardless of the casts you do, you ultimately have to call using a matching prototype. The initial IR looks like a violation of that rule.</p>
<p dir="ltr">>> Sent from phone<br>
>><br>
>> On Jan 4, 2015 4:35 PM, "Philip Reames" <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>> wrote:<br>
>>><br>
>>> On 01/04/2015 12:04 AM, Liu Xin wrote:<br>
>>>><br>
>>>><br>
>>>> %294= callfloatbitcast (float(float, float*)* @__gpu_modff to float(float, i64)*)(float%293, i64 %preg.212.addr.0)<br>
>>>><br>
>>>> as you may know, some gpu backends don't support function call. we need to make sure to inline all functions here. however, Inliner can not figure out that this is a valid callsite in this form. actually, it is.  in C words, cast a function and then call should be treat as callsite, right?<br>
>>>><br>
>>> Generally, the inliner doesn't do much with indirect calls, but given there is no simpler canonical case here, I expect we'll have to.<br>
>>><br>
>>> Its possible we might even want to define this as a direct call. I'm not sure what the expectations are with regards to the type of the function being called and the type of the callsite.  I suspect a lot of code would get confused if getCalledFunction returned __gpu_modff with it's unbitcast type.  That's possibly something we should fix though.<br>
>>><br>
>>> We'll want to get other folks input here, but a small patch to the inliner to handle this case would seem reasonable to me.<br>
>>><br>
>>> Philip<br>
>>> _______________________________________________<br>
>>> LLVM Developers mailing list<br>
>>> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br>
>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
><br>
</p>