<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 18 March 2014 23:11,  <span dir="ltr"><<a href="mailto:7d89a89974b0ff40.invalid@internationalized.invalid" target="_blank">7d89a89974b0ff40.invalid@internationalized.invalid</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On Saturday, 15 March 2014 at 04:17:06 UTC, Manu wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'd say it should inline only func. Any sub-calls are subject to the<br>
regular inline heuristics.<br>
</blockquote>
<br></div>
I agree with you that explicit inlining is absolutely necessary and that call site inlining is highly desirable. However, I think that the call-site inlining should inline as much as possible. Basically this is something you will try when the code is too slow to meet real time deadlines and you hope to avoid going for a hand optimized solution in order to cut down on dev time. That suggests aggressive inlining to me.<br>
</blockquote><div><br></div><div>Inlining is a basic codegen tool, and it's important that low-level programmers have tight control over this aspect of the compiler's codegen. I think it's a mistake to consider it an optimisation, unless you know precisely what you're doing.</div>
<div>I wouldn't want to see it try and forcibly inline the whole tree; there's no reason to believe that the whole tree should be inlined 100% of the time, rather, it's almost certainly not the case.</div><div>
In the case you do want to inline the whole tree, you can just cascade the mixin through the stack. In the case you suggest which flattens the tree by default, we've lost control; how to tell it only to do it for one level without hacks? And I believe this is the common case.</div>
<div><br></div><div>For example, It's very likely that you might require a function to inline that is relatively trivial in its own right; a wrapper or a macro effectively, but conditionally calls an expensive function, or perhaps calls a function that you don't have source for (it would break at that point if it tried to inline the tree).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If the inlining only goes one level then I don't think this will be used frequently enough to be useful, e.g. you can just create one inline version and then a non-inline version that calls the inline version.<br></blockquote>
<div><br></div><div>As the one that requested it, I have numerous uses for it to mixin just the one level. I can't imagine any uses where I would ever want to explicitly inline the whole tree, and not be happy to cascade it manually.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
E.g.:<br>
<br>
noninline_func(){ inline_func();}<br></blockquote><div><br></div><div>Why? This is really overcomplicating a simple thing. And I'm not quite sure what you're suggesting this should do either. Are you saying the call tree is flattened behind this proxy non-inline function? I don't think that's useful.</div>
<div>I don't think anything would/should be marked __alwaysinline unless you REALLY mean that it has literally no business being called. Ie, marking something __alwaysinline just for the sake of wrapping it with a non-inline is the wrong thing to do.<br>
</div><div><br></div><div>Just to reiterate, inline is a tool, not an 'optimisation'. It doesn't necessarily yield faster code, in many situations it is slower, and best left to the compiler to decide. But it's an important tool for any low-level programmer to have. D must provide a sufficient suite of low-level tools that allow proper control over the code generation. I think as a tool, it should be deliberate and conservative in approach, ie, just one level, and let the programmer cascade it if that's what they mean to do. There should be no surprises with something like this, and if it's inlining a whole call tree, you often don't know what happens further down the tree, and it's more likely to change on you unexpectedly.</div>
</div></div></div>