%294 = call float bitcast (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? thanks, --lx -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150104/60734c2e/attachment.html>
> On Jan 4, 2015, at 12:04 AM, Liu Xin <navy.xliu at gmail.com> wrote: > > %294 = call float bitcast (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? > >LLVM’s inliner does not support indirect calls. I have encountered the same problem before, but instead of adding support for indirect call, it might be easier to modify the code to generate the accurate function signature and thus avoid the explicit cast. thanks, chen> thanks, > > --lx > > > > _______________________________________________ > 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/51d78baf/attachment.html>
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
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 specificallywhat "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 isUB, 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 yousuggesting 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 tofloat(float, i64)*)(float%293, i64 %preg.212.addr.0)>>>> >>>> as you may know, some gpu backends don't support function call. weneed 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 giventhere 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'mnot 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 theinliner 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>
Philip, I post here because I think AlwaysInliner should inline it. I want to detect the indirect calls for Inliner, and I want to hear inputs. let me define indirect call first in my idea. In one single expression, one function may be subject to bitcast more than one time. we can detect this situation and treat it as a regular call of last function, is that okay? thanks, --lx On Mon, Jan 5, 2015 at 7:32 AM, 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150105/5016835d/attachment.html>