inlining...

[Manu]

On 18 March 2014 23:11,
<7d89a89974b0ff40.invalid at internationalized.invalid>wrote:

> On Saturday, 15 March 2014 at 04:17:06 UTC, Manu wrote:
>
>> I'd say it should inline only func. Any sub-calls are subject to the
>> regular inline heuristics.
>>
>
> 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.
>

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.
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.
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.

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).

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.
>

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.

E.g.:
>
> noninline_func(){ inline_func();}
>

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.
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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140319/5202bb2d/attachment-0001.html>