inlining...

[Puming]

Maybe we could have both declare site inlining and call site 
inlining.

with declare site, what we mean is that this function's body is 
used so commonly that we make it into a function only because we 
don't want duplicate code, not because it should be a standalone 
function.

with call site inlining, one can inline thirdparty functions 
which is not declared inline.

I think the `inline` Manu suggested should not be viewed as a 
mere optimization thing, but more like a code generation utility 
which happens to be faster. In this point of view, this kind of 
`inline` should be controlled by the coder, not the compiler.

To make it clear that we are not talking about optimization, 
maybe we should call it another name, like 'mixin function'?

BTW, the Kotlin language recently get a new released, which added 
support for declare site force inline, the team argues its 
necessity here:

http://blog.jetbrains.com/kotlin/2014/03/m7-release-available/#more-1439

in the comments:
>It’s traditional to think about inlining as a mere optimization, 
>but this dates back to the times >when software was shipped as 
>one huge binary file.
>
>Why we think inline should be a language feature:
>1. Other language features (to be implemented soon) depend on 
>it. Namely, non-local returns >and type-dependent functions. 
>Basically, inline functions are very restricted macros, and this 
>>is definitely a language feature.
>2. Due to dynamic linking and binary compatibility issues it can 
>not be up to the compiler >whether to inline something or not on 
>the JVM: if bodies of inline functions change, all >dependent 
>code should be recompiled, i.e. it’s the library author’s 
>liability to preserve >functionality, so such functions must be 
>explicitly marked.

On Thursday, 20 March 2014 at 02:08:16 UTC, Manu wrote:
> On 20 March 2014 06:23,
> <7d89a89974b0ff40.invalid at internationalized.invalid>wrote:
>
>> On Wednesday, 19 March 2014 at 12:35:30 UTC, Manu wrote:
>>
>>> Okay, do you have use cases for any of this stuff? Are you 
>>> just making it
>>> up, or do you have significant experience to say this is what 
>>> you need?
>>>
>>
>> I don't need anything, I hand optimize prematurely. And I 
>> don't want to do
>> that.
>>
>> But yes, inner loops benefits from exhaustive inlining because 
>> you get to
>> move common expressions out of the loop or change them to 
>> delta increments.
>> It is only when you trash the caches that inlining does not 
>> pay off.
>>
>> I do it by hand. I don't want to do it by hand.
>>
>>
>>  If you ask me, I have no value in recursive inlining, infact, 
>> that would
>>> anger me considerably.
>>>
>>
>> Why? You could always set the depth to 1, or make 1 the 
>> default.
>>
>> And it isn't difficult to implement.
>>
>
> The problem is upside down. If you want to inline multiple 
> levels, you
> start from the leaves and move downwards, not from the root 
> moving upwards
> (leaving a bunch of leaves perhaps not inlined), which is what 
> you're
> really suggesting.
> Inlining should be strictly deliberate, there's nothing to say 
> that every
> function called in a tree should be inlined. There's a high 
> probability
> there's one/some that shouldn't be among a few that should.
>
> Remember too, that call-site inlining isn't the only method, 
> there would
> also be always-inline. I think always-inline is what you want 
> for some
> decidedly trivial functions (although these will probably be 
> heuristically
> inlined anyway), not call-site inlining. I just don't see how 
> recursive
> call-site inlining is appropriate, considering that call trees 
> are often
> complex, subject to change, and may even call functions that 
> you don't have
> source for. You can cascade the mixin keyword if you want to, 
> that's very
> simple. I'd be highly surprised if you ever encountered a call 
> tree where
> you wanted to inline everything (and the optimiser didn't do it 
> for you).
> As soon as you encounter a single function in the tree that 
> shouldn't be
> inlined, then you'll be forced to do it one level at a time 
> anyway.