<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Sep 4, 2018, at 2:32 PM, Jakub (Kuba) Kuderski via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><div class=""><div dir="ltr" class=""><span id="gmail-docs-internal-guid-f3ce49b6-7fff-f1e4-5c8b-de44c3c1ede0" class=""><div style="line-height: 1.38; margin-top: 0pt; margin-bottom: 0pt;" class=""><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class="">Hi folks,</span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class=""><br class="gmail-kix-line-break"></span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class=""><br class="gmail-kix-line-break"></span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class="">TL;DR: I propose to add 3 new C/C++ intrinsics for controlling inlining at callsite:</span></div><span style="background-color: transparent; white-space: pre-wrap; font-family: Arial;" class="">* __builtin_no_inline(Foo()) -- prevents the call to Foo() from being inlined at that particular callsite.</span><br class=""><span style="background-color: transparent; white-space: pre-wrap; font-family: Arial;" class="">* __builtin_always_inline(Foo()) -- inlines this call to Foo(), if possible.</span><br class=""><span style="background-color: transparent; font-family: Arial; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class="">* __builtin_flatten_inline(Foo()) -- inlines this call to Foo() and (transitively) everything called within Foo’s body.</span><span style="background-color: transparent; font-family: Arial; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class=""><br class="gmail-kix-line-break"></span><div style="line-height: 1.38; margin-top: 0pt; margin-bottom: 0pt;" class=""><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class="">These intrinsics apply to the outermost call-like expression and it will be possible to use them with: function calls, member function calls, operator calls, constructor calls, indirect calls (with function pointers, member function pointers, virtual calls).</span></div></span></div></div></blockquote><div><br class=""></div>Would it make sense to pre-emptively generalize this as a call-annotation builtin that takes the annotations as a second, string-literal argument? Or maybe even has some special parsing rules so that we can e.g. parse attributes in the later operands? Call-related features tend to end up with a million different variations; you already have three different builtins for three different inlining behaviors, and once this infrastructure is up and working, I expect we'll want to add more for all sorts of other call-related mechanisms. To me, that means it makes sense to plan this as a more heavyweight language feature, including things like preparing for call sites that the user wants to apply multiple annotations to.</div><div><br class=""></div><div>For `__builtin_flatten_inline`, there are sometimes a lot of implicit calls done on behalf of emitting the primary call: `operator->`, default arguments, copy constructors for arguments, destructors for arguments, that kind of thing. Are these covered? Not covered because they're emitted with the caller? Is it okay for the semantics to differ by target for things like argument destructors?</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><span id="gmail-docs-internal-guid-f3ce49b6-7fff-f1e4-5c8b-de44c3c1ede0" class=""><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class="">One thing I’m not sure about is what to do when the expression inside inline intrinsic doesn’t happen to be any kind of call. It doesn’t make much sense to be able to write something like:</span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class=""><br class="gmail-kix-line-break"></span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class="">__builtin_always_inline(1 + 3), but what may happen in generic context (e.g.,</span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class=""><br class="gmail-kix-line-break"></span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class="">__builtin_always_inline(t + u)), is that it’s not known if expressions will end up operating on primitive types or user-defined ones that actually make function calls. In my opinion, it will make life easier if inline intrinsics over non-call-like expressions will be treated as no-ops, in any context, as the compiler can already reason about them and won’t perform any function calls. One option is to silently not inline when the compiler resolves the call to an operation, which would be consistent with the behavior of silently not inlining calls it cannot resolve. Alternatively we may emit warnings, which would make maintaining code with these intrinsics easier.</span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class=""><br class="gmail-kix-line-break"></span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class="">I’d really like to get feedback on this issue.</span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class=""><br class="gmail-kix-line-break"></span></span></div></div></blockquote><div><br class=""></div>This should definitely be a parse-time error. In a template, you can recognize and decline to diagnose dependent expressions that might be instantiated to a call, which I believe just means the allowing BinaryOperator and UnaryOperator when one of the operands has a dependent type.</div><div><br class=""></div><div>John.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><span id="gmail-docs-internal-guid-f3ce49b6-7fff-f1e4-5c8b-de44c3c1ede0" class=""><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class=""><br class="gmail-kix-line-break"></span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class="">Implementation:</span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class=""><br class="gmail-kix-line-break"></span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class="">I have already partially implemented the first two intrinsics (__builtin_no_inline and __builtin_always_inline) here: </span><a href="https://reviews.llvm.org/D51200" style="text-decoration-line:none" class=""><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;text-decoration-line:underline;vertical-align:baseline;white-space:pre-wrap" class="">https://reviews.llvm.org/D51200</span></a><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class="">. Calls wrapped with the inline intrinsics are annotated with appropriate attributes during code generation. LLVM seems to already take care of callsites attributed with alwaysinline and noinline. I think it should also be possible to implement some appropriate attribute for flattening, as there’s already gnu::flatten attribute for function declarations.</span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class=""><br class="gmail-kix-line-break"></span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class=""><br class="gmail-kix-line-break"></span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class="">Let me know what you think,</span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class=""><br class="gmail-kix-line-break"></span><span style="font-family: Arial; background-color: transparent; font-variant-numeric: normal; font-variant-east-asian: normal; vertical-align: baseline; white-space: pre-wrap;" class="">Kuba</span></span><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div class="">Jakub Kuderski</div></div></div>
_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></blockquote></div><br class=""></body></html>