inlining...

[Manu]

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

> On Wednesday, 19 March 2014 at 08:35:53 UTC, Manu wrote:
>
>> 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.
>>
>
> Not if you delay optimization until profiling and focus on higher level
> structures during initial implementation. Or use composing (like generic
> programming).
>
> If you hand optimize right from the start then you might be right, but if
> you never call a function with the same parameters then you are doing
> premature optimization IMHO.
>

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 can say for a fact, that recursive inline would make almost everything I
want it for much more annoying. I would find myself doing stupid stuff to
fight the recursive inliner in every instance.

 When the function is generated code (not hand written).
>>>
>>
>> I'm not sue what you mean here?
>>
>
> Code that is generated by a tool (or composable templates or whatever)
> tend to be repetitive and suboptimal. I.e. boiler plate code that looks
> like it was written by a monkey…
>

I'm not sure where the value is... why would you want to inline this?

 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.
>>
>
> I meant that if you have explicit inline hints like C++ then you also have
> call-site inlining if you want to.


I still don't follow. C++ doesn't have call-site inlining. C/C++ has
macros, and there is no way to achieve the same functionality in D right
now, that's a key motivation for the proposal.

 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.
>>
>
> That should be considered a bug if it is called from more than one
> location.
>

Seriously, you're making 'inline' about 10 times more complicated than it
should ever be.
If you ask me, I have no value in recursive inlining, infact, that would
anger me considerably.

By making this hard, you're also making it equally unlikely. Let inline
exist first, then if/when it doesn't suit your use cases, argue for the
details.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140319/92632581/attachment.html>