<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 15 March 2014 03:57, Jacob Carlborg <span dir="ltr"><<a href="mailto:doob@me.com" target="_blank">doob@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On 2014-03-14 07:21, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, I'm constantly running into issues with not having control over inline.<br>
I've run into it again doing experiments in preparation for my dconf talk...<br>
<br>
I have identified 2 cases which come up regularly:<br>
  1. A function that should always be inline unconditionally (std.simd<br>
is effectively blocked on this)<br>
  2. A particular invocation of a function should be inlined for this<br>
call only<br>
<br>
The first case it just about having control over code gen. Some<br>
functions should effectively be macros or pseudo-intrinsics (ie,<br>
intrinsic wrappers in std.simd, beauty wrappers around asm code, etc),<br>
and I don't ever want to see a symbol appear in the binary.<br>
<br>
My suggestion is introduction of __forceinline or something like it. We<br>
need this.<br>
</blockquote>
<br></div>
Haven't we already agreed a pragma for force inline should be implemented. Or is that something I have dreamed?</blockquote><div><br></div><div>It's been discussed. I never agreed to it (I _really_ don't like it), but I'll take it if it's the best I'm gonna get.</div>
<div><br></div><div>I don't like stateful attributes like that. I think it's error prone, especially when it's silent.<br></div><div>'private:' for instance will complain if you write a new function in an area influenced by the private state and try and call it from elsewhere; ie, you know you made the mistake.<br>
</div><div>If you write a new function in an area influenced by the forceinline state which wasn't intended to be inlined, you won't know. I think that's dangerous.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The second case is interesting, and I've found it comes up a few times<br>
on different occasions.<br>
In my current instance, I'm trying to build generic framework to perform<br>
efficient composable data processing, and a basic requirement is that<br>
the components are inlined, such that the optimiser can interleave the<br>
work properly.<br>
<br>
Let's imagine I have a template which implements a work loop, which<br>
wants to call a bunch of work elements it receives by alias. The issue<br>
is, each of those must be inlined, for this call instance only, and<br>
there's no way to do this.<br>
I'm gonna draw the line at stringified code to use with mixin; I hate<br>
that, and I don't want to encourage use of mixin or stringified code in<br>
user-facing API's as a matter of practise. Also, some of these work<br>
elements might be useful functions in their own right, which means they<br>
can indeed be a function existing somewhere else that shouldn't itself<br>
be attributed as __forceinline.<br>
<br>
What are the current options to force that some code is inlined?<br>
<br>
My feeling is that an ideal solution would be something like an<br>
enhancement which would allow the 'mixin' keyword to be used with<br>
regular function calls.<br>
What this would do is 'mix in' the function call at this location, ie,<br>
effectively inline that particular call, and it leverages a keyword and<br>
concept that we already have. It would obviously produce a compile error<br>
of the code is not available.<br>
<br>
I quite like this idea, but there is a potential syntactical problem;<br>
how to assign the return value?<br>
<br>
int func(int y) { return y*y+10; }<br>
<br>
int output = mixin func(10); // the 'mixin' keyword seems to kinda 'get<br>
</blockquote>
<br></div></div>
I think this is the best syntax of these three alternatives.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
in the way' if the output<br>
int output = mixin(func(10)); // now i feel paren spammy...<br>
</blockquote>
<br></div>
This syntax can't work. It's already interpreted calling "func" and use the result as a string mixin.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
mixin(int output = func(10)); // this doesn't feel right...<br>
</blockquote>
<br></div>
No.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My feeling is the first is the best, but I'm not sure about that<br>
grammatically.<br>
</blockquote>
<br></div>
Yeah, I agree.</blockquote><div><br></div><div>So you think it's grammatically okay?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The other thing that comes to mind is that it seems like this might make<br>
a case for AST macros... but I think that's probably overkill for this<br>
situation, and I'm not confident we're ever gonna attempt to crack that<br>
nut. I'd like to see something practical and unobjectionable preferably.<br>
</blockquote>
<br></div>
AST macros would solve it. It could solve the first use case as well. I would not implement AST macros just to support force inline but we have many other uses cases as well. I would have implement AST macros a long time ago. Hopefully this would avoid the need to create new language features in some cases.<br>

<br>
First use case, just define a macro that returns the AST for the content of the function you would create.<br>
<br>
macro func (Ast!(int) a)<br>
{<br>
    return <[ $a * $a; ]>;<br>
}<br>
<br>
int output = func(10); // always inlined<br>
<br>
Second use case, define a macro, "inline", that takes the function you want to call as a parameter. The macro will basically inline the body.<br>
<br>
macro inline (T, U...) (Ast!(T function (U) func)<br>
{<br>
    // this would probably be more complicated<br>
    return func.body;<br>
}<br>
<br>
int output = func(10); // not inlined<br>
int output = inline(func(10)); // always inlined<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This problem is fairly far reaching; phobos receives a lot of lambdas<br>
these days, which I've found don't reliably inline and interfere with<br>
the optimisers ability to optimise the code.<br>
</blockquote>
<br></div>
I thought since lambdas are passed as template parameters they would always be inlined.</blockquote><div><br></div><div>Maybe... (and not in debug builds). Without explicit control of the inliner, you just never know.</div>
</div></div></div>