[cfe-dev] [RFC] Per-callsite inline intrinsics

Jakub Kuderski via cfe-dev cfe-dev at lists.llvm.org
Tue Sep 4 12:31:35 PDT 2018


>
>  they seem like very surgical tools for controlling inlining, and so
> applying them to a family of functions is perhaps unwise -- and the case
> where the builtin is applied to a call in some instantiations and to a
> built-in operator in others does not immediately seem like a primary
> concern to me
>
Having seen a lot of library and game engine code with FORCE_INLINE stuck
on dozens functions, I'd eventually expect it to become an issue for some
people. However, I think it would be easier to start simple and issue
errors in any case where these intrinsics don't make sense, and relax it
later if there's a real need.

(Are there also macro scenarios where you anticipate it being unknown
> whether the operand is a function call?)
>
Arthur O'Dwyer pointed that out in the code review -- one example could be
sqrt being a function call or a builtin call. Another thing that comes to
my mind is `min` from windows.h.


On Tue, Sep 4, 2018 at 11:53 AM Jon Chesterfield via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> This is a good idea. I've been working around the absence of this by
> writing wrapper functions tagged with the corresponding metadata.
>
> I don't know clang well enough to review the implementation, but if it
> ships, I'll use it. Whatever the syntax.
>
> Thanks
>
>
> Hi folks,
>>
>> TL;DR: I propose to add 3 new C/C++ intrinsics for controlling inlining at
>> callsite:
>> * __builtin_no_inline(Foo()) -- prevents the call to Foo() from being
>> inlined at that particular callsite.
>> * __builtin_always_inline(Foo()) -- inlines this call to Foo(), if
>> possible.
>> * __builtin_flatten_inline(Foo()) -- inlines this call to Foo() and
>> (transitively) everything called within Foo’s body.
>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180904/13e97c54/attachment.html>


More information about the cfe-dev mailing list