inlining...

Manu turkeyman at gmail.com
Wed Mar 19 01:35:07 PDT 2014


On 19 March 2014 16:18,
<7d89a89974b0ff40.invalid at internationalized.invalid>wrote:

> On Wednesday, 19 March 2014 at 01:28:48 UTC, Manu wrote:
>
>> 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.
>>
>
> You could provide it with a recursion level parameter or parameters for
> cost level heuristics.
>

Again, I think this is significantly overcomplicating something which see
is being extremely simple.

It could also be used to flatten tail-call recursion.


I don't think it's valid to inline a tail call recursion, because the
inlined call also wants to inline another call to itself...
You can't know how fer it should go, so it needs to be transformed into a
loop, and not we're talking about something completely different than
inlining.

 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.
>>
>
> In innerloops to factor out common subexpressions that are otherwise
> recomputed over and over and over.
>

This is highly context sensitive. I would trust the compiler heuristics to
make the right decision here.
The idea of eliminating common sub-expressions suggests that there _are_
common sub-expressions, which aren't affected by the function arguments.
This case is highly unusual in my experience. And I personally wouldn't
depend on a feature such as this to address that sort of a problem in my
codegen. I would just refactor the function a little bit to call the common
sub-expression ahead of time.

When the function is generated code (not hand written).


I'm not sue what you mean here?

 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?
>>
>
> No, I am saying that the one level mixin doesn't provide you with anything
> new.


It really does provide something new. It provides effectively, a type-safe
implementation of something that may be used in place of C/C++ macros. I
think that would be extremely useful in a variety of applications.

You already have that. It is sugar.
>

I don't already have it, otherwise I'd be making use of it. D has no
control over the inliner. GDC/LDC offer attributes, but then it's really
annoying that D has no mechanism to make use of compiler-specific
attributes in a portable way (ie, attribute aliasing), so I can't make use
of those without significantly interfering with my code.

I also don't think that suggestion of yours works. I suspect the compiler
will see the outer function as a trivial wrapper which will fall within the
compilers normal inline heuristics, and it will all inline anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140319/4b2add28/attachment-0001.html>


More information about the Digitalmars-d mailing list