DIP56 Provide pragma to control function inlining

Manu turkeyman at gmail.com
Mon Feb 24 08:34:19 PST 2014


On 25 February 2014 02:30, Manu <turkeyman at gmail.com> wrote:

> This will probably do, but I still don't understand why not a function
> attribute?
>

Note; GDC and LDC already have inline attributes. It's a pain in the arse
to use them though, since in D, we have no way to alias attributes and
can't do the typical C preprocessor tricks to insert appropriate attributes
for different compilers.
I'd strongly encourage considering making it an attribute for the reason
that all compilers could then share the same attribute, rather than
remaining fragmented as it is.


Will marking a function as inline notify the compiler that code should
> never be emitted to object files for that function?
>
> Perhaps OT:
> I've been playing with ranges a lot recently, and std.algorithm and
> friends, and I'm finding that using lambdas is real problem. They don't
> reliably inline, and the optimiser seems to have problems on occasion even
> when they do. (Perhaps they inline at the wrong stage?)
> How can we have some guarantees about the inlining and inline-ability of
> trivial lambda's?
> I'm very concerned about the performance of debug code when using
> something like filter!"condition", which results in a whole bunch of extra
> function calls per loop iteration.
> I raised a thread recently about the idea of adding an additional optional
> argument to foreach to provide a filtering or termination condition, which
> if implemented by the language would have no overhead cost. The suggestion
> was to use filter!"", which sounds like a reasonable idea, but I'm really
> worried about the performance implications of using library primitives that
> produce a bunch of extra function calls on every loop cycle. I'm not sure
> these are practical when used in sufficiently trivial loops. Imagine I'm
> looping over a vertex array or an image or something, skipping over
> transparent pixels, or something like that... millions of iterations
> performing very trivial transformation, calling a bunch of functions every
> cycle.
>
> On 23 February 2014 22:07, Walter Bright <newshound2 at digitalmars.com>wrote:
>
>> http://wiki.dlang.org/DIP56
>>
>> Manu has needed always inlining, and I've needed never inlining. This DIP
>> proposes a simple solution.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140225/aef52408/attachment-0001.html>


More information about the Digitalmars-d mailing list