<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 20 March 2014 18:35,  <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 Thursday, 20 March 2014 at 02:08:16 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">
The problem is upside down. If you want to inline multiple levels, you<br>
start from the leaves and move downwards, not from the root moving upwards<br>
</blockquote>
<br></div>
Yes, that is true in cases where leaves are frequently visited. Good point. I am most interested in full inlining, but the heuristics should probably start with the leaves for people not interested in that. Agree.<br>
<br>
Anyway, in the case of ray tracing (or any search structure) I could see the value of having the opposite in combination with CTFE/partial evaluation.<br>
<br>
Example: Define a static scene (of objects) and let the compiler turn it into "a state machine" of code.<br>
<br>
Another example: Define an array of data, use partial evaluation to turn it into a binary tree, then turn the binary tree into code.<div class=""><br>
<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">
Inlining should be strictly deliberate, there's nothing to say that every<br>
function called in a tree should be inlined. There's a high probability<br>
there's one/some that shouldn't be among a few that should.<br>
</blockquote>
<br></div>
In the case of a long running loop it does not really matter. What it does get you is a chance to use generic code (or libraries) and then do a first-resort optimization. I basically see it as a time-saving feature (programmers time). A tool for cutting development costs.<br>

<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="">
Remember too, that call-site inlining isn't the only method, there would<br></div>
also be always-inline...<br>
</blockquote>
<br>
Yes, that is the first. I have in another thread some time ago suggested a solution that use weighted inlining to aid compiler heuristics:<br>
<br>
<a href="http://forum.dlang.org/thread/szjkyfpnachnnyknnfwp@forum.dlang.org#post-szjkyfpnachnnyknnfwp:40forum.dlang.org" target="_blank">http://forum.dlang.org/thread/<u></u>szjkyfpnachnnyknnfwp@forum.<u></u>dlang.org#post-<u></u>szjkyfpnachnnyknnfwp:40forum.<u></u>dlang.org</a><br>

<br>
As you can see I also suggested call-site inlining, so I am fully behind you in this. :-) Lack of inlining and GC are my main objections to D.<div class=""><br>
<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 think always-inline is what you want for some<br>
decidedly trivial functions (although these will probably be heuristically<br>
inlined anyway), not call-site inlining.<br>
</blockquote>
<br></div>
I agree. Compiler heuristics can change. It is desirable to be able to express intent no matter what the current heuristics are.<div class=""><br>
<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 just don't see how recursive<br>
call-site inlining is appropriate, considering that call trees are often<br>
complex, subject to change, and may even call functions that you don't have<br>
source for.<br>
</blockquote>
<br></div>
You should not use it blindly.<div class=""><br>
<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">
You can cascade the mixin keyword if you want to, that's very simple.<br>
</blockquote>
<br></div>
Not if you build the innerloop using generic components. I want this<br>
<br>
inline_everything while(conditon){<br>
statement;<br>
statement;<div class=""><br>
}<br>
<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 be highly surprised if you ever encountered a call tree where<br>
you wanted to inline everything (and the optimiser didn't do it for you).<br>
</blockquote>
<br></div>
Not if you move to high-level programming using prewritten code and only go low level after profiling.<div class=""><br>
<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">
As soon as you encounter a single function in the tree that shouldn't be<br>
inlined, then you'll be forced to do it one level at a time anyway.<br>
</blockquote>
<br></div>
But then you have to change the libraries you are using!?<br>
<br>
Nothing prevents you to introduce exceptions as an extension though. I want inline(0.5) as default, but also be able to write inline(1) for inline always and inline(0) for inline never.<br>
<br>
func1(){} // implies inline(0.5) weighting<br>
inline func2(){} // same as inline(1) weighting, inline always<br>
inline(0.75) fun31(){} // increase the heuristics weighting<br>
inline(0) func4(){} // never-ever inline<br>
<br>
Ola.<br>
</blockquote></div><br></div><div class="gmail_extra">I'm sorry. I really can't support any of these wildly complex ideas. I just don't feel they're useful, and they're not very well founded.</div><div class="gmail_extra">
A numeric weight? What scale is it in? I'm not sure of any 'standard-inline-weight-measure' that any programmer would be able to intuitively gauge the magic number against. That will simply never be agreed by the devs.</div>
<div class="gmail_extra">It also doesn't make much sense... different platforms will assign very different weights and different heuristics at the inliner. It's not a numeric quantity; it's a complex determination whether a function is a good candidate or not.</div>
<div class="gmail_extra">The value you specify is likely highly context sensitive and probably not portable. Heuristic based Inlining should be left to the optimiser to decide.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
And I totally object to recursive inlining. It has a kind of absolute nature that removes control all the way down the call tree, and I don't feel it's likely that you would often (ever?) want to explicitly inline an entire call tree.</div>
<div class="gmail_extra">If you want to inline a second level, then write mixin in the second level. Recurse.</div><div class="gmail_extra">You are talking about generic code as if this isn't appropriate, but I specifically intend to use this in generic code very similar to what you suggest; so I don't see the incompatibility.</div>
<div class="gmail_extra">I think you're saying like manually specifying it all the way down the call tree is inconvenient, but I would argue that manually specifying *exclusions* throughout the call tree after specifying a recursive inline is even more inconvenient. It requires more language (a feature to mark an exclusion), has a kind of obtuse double-negative logic about it, and it's equally invasive to your code.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">If you can prove that single level call-site inlining doesn't satisfy your needs at some later time, make a proposal then, along with your real-world use cases. But by throwing it in this thread right now, you're kinda just killing the thread, and making it very unlikely that anything will happen at all, which is annoying, because I REALLY need this (I've been trying to motivate inline support for over 3 years), and I get the feeling you're just throwing hypotheticals around.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">You're still fairly new here, but be aware that feature requests will become exponentially less likely to be accepted with every degree of complexity added. By making this seem hard, you're also making it almost certain not to happen, which isn't in either of our interest.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">My OP suggestion is the simplest solution I can conceive which will definitely satisfy all the real-world use cases that I've ever encountered. Is predictable, portable, simple.</div>
</div>