[LLVMdev] should AlwaysInliner inline this case?

[Reid Kleckner]

On Jan 4, 2015 5:37 PM, "Philip Reames" <listmail at philipreames.com> wrote:
>
> Did you intend to reply only to me on this?

Oops.

> On 01/04/2015 03:46 PM, Reid Kleckner wrote:
>>
>> 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.
>
> I'm not quite sure what you meant by this.  Can you clarify specifically
what "should work" means?

Just that bitcasting the caller arg types to the callee's parameter types
and removing the indirect call should be semantically equivalent.

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

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.

>> Sent from phone
>>
>> On Jan 4, 2015 4:35 PM, "Philip Reames" <listmail at philipreames.com>
wrote:
>>>
>>> On 01/04/2015 12:04 AM, Liu Xin wrote:
>>>>
>>>>
>>>> %294= callfloatbitcast (float(float, float*)* @__gpu_modff to
float(float, i64)*)(float%293, i64 %preg.212.addr.0)
>>>>
>>>> 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?
>>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Philip
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150104/4dc39a49/attachment.html>