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

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

On 25 February 2014 02:30, Manu <turkeyman@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@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.
>>
>
>

On 23 February 2014 22:57, Walter Bright <newshound2@digitalmars.com> wrote:

> On 2/23/2014 4:25 AM, Tove wrote:
>
>> The DIP should probably specify what happens if inlining fails, i.e. generate a compilation error.
>>
>
> I suspect that may cause problems, because different compilers will have different inlining capabilities. I think it should be a 'recommendation' to the compiler.
>

Does this depend how it is implemented?
Will DMD just patch it directly into the AST like a mixin in the front end,
or is it always left to the back end?

On 23 February 2014 22:55, Walter Bright <newshound2@digitalmars.com> wrote:

> On 2/23/2014 4:53 AM, ponce wrote:
>
>> On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote:
>>
>>> http://wiki.dlang.org/DIP56
>>>
>>> Manu has needed always inlining, and I've needed never inlining. This DIP proposes a simple solution.
>>>
>>
>> This is great. I bet this will be useful.
>>
>> I tend to prefer force-inline/force-not-inline at call site, but realized
>> the
>> proposal will let me do it:
>>
>> void myFun(bool inlined)(int arg)
>> {
>>      static if (inlined)
>>          pragma(inline, true);
>>      else
>>          pragma(inline, false);
>> }
>>
>> Then inlining can be entirely explicit :)
>>
>
> Or better:
>
> void myFun(bool inlined)(int arg)
> {
>     pragma(inline, inlined);
> }
>
> :-)
>

Really? I think you're just trying to be different for the sake of being different :P

On 24 February 2014 07:53, Walter Bright <newshound2@digitalmars.com> wrote:

>
>  With error - yo get a huge advantage - an _instant_ feedback that it
>> doesn't do
>> what you want it to do. Otherwise it gets the extra pleasure of running
>> disassembler to pinpoint your favorite call sites or observing that your
>> profiler shows the same awful stats.
>>
>
> My point is you're going to have to look at the asm of the top functions on the profiler stats anyway, or you're wasting your time trying to optimize the code. (Speaking from considerable experience doing that.) There's a heluva lot more to optimizing effectively than inlining, and it takes some back-and-forth tweaking source code and looking at the assembler. I gave some examples of that above.
>

For those interested, in my experience, the value of inlining is rarely
related to eliminating the cost of the function call. call and ret have
virtually no impact on performance on any architecture I've used.
The main value is that it eliminates stuffing around with parameter lists,
and managing save registers. Also, some argument types can't pass in
registers, which means they pass through memory, and memory access should
be treated no differently from the hard drive in realtime code ;) .. The
worst case is a write followed by an immediate read (non-register argument,
or save register value); some architectures stall waiting for the full
flush before they can read it back. It's called a Load-Hit-Store hazard,
and it's the most expensive low level hazard short of an L2 miss.
But the most important use by far is that you can control which functions
are leaf functions. Leaf functions (functions that don't allocate a stack
frame at all) are critical for good performance. Any small helper functions
you call MUST be inlined, or your function is no longer eligible to be a
leaf function.

I agree that inline should be a hint (a STRONG hint, not like 'inline' in C, more like __force_inline, perhaps stronger), but I'd like it if I received a warning when it failed for whatever reason. I don't want it to stop compiling, but a nice notification that I should look into it, and the ability to disable/silence the warning if I can't/don't intend to.

On Monday, 24 February 2014 at 02:05:31 UTC, Walter Bright wrote:
> 1. It provides information to the compiler about runtime frequency that it cannot obtain otherwise. This is very useful information for generating better code.
>

> 2. Making it a hard requirement then means the user will have to put versioning in it. It becomes inherently non-portable. There is no way to predict what some other version of some other compiler on some other system will do.
>
I'm not sure what it is impossible to inline in some case, I've never hit that limitation with ICC.
Like others I would like unconditional and explicit optimization from the compiler.

> 3. In the end, the compiler should make the decision. Inlining does not always result in faster code, as I pointed out in another post.

Also when I use "force inline" it's very often to force "not-inline" to reuse the same bit of code while the compiler would have inlined it.

Each optimization here is taken a repeatable automated A-B test with a 95% statistical significance on various inputs, and forcing inline/not-inline has been an effective tool to reduce the I-cache stress that plagues some very particular program areas that the compiler doesn't differentiate. This can be checked by looking at assembly or binary size afterwards.

I'm perfectly OK with the compiler doing what he wants when I don't tell it to inline or not. AFAIK the C/C++ inline keyword is mostly ignored by optimizing compilers, it's precisely a keyword that is both overused and meaningless.


> Perhaps the lesson is the word 'inline' carries certain expectations with it, and the feature would be better positioned as something like:
>
>     pragma(usage, often);
>     pragma(usage, rare);

To me it's not so much about usage frequency that about I-cache misses. Some inlining can be nearly free (I-cache working set small), or very costly (I-cache actively being the bottleneck through repeated miss due to large working set).

On Monday, 24 February 2014 at 16:58:21 UTC, Manu wrote:
> I agree that inline should be a hint (a STRONG hint, not like 'inline' in
> C, more like __force_inline, perhaps stronger), but I'd like it if I
> received a warning when it failed for whatever reason. I don't want it to
> stop compiling, but a nice notification that I should look into it, and the
> ability to disable/silence the warning if I can't/don't intend to.

Perhaps something like a -vinline similar to -vtls? You don't
need to be spammed repeatedly every time you build saying
something isn't inlined, yet this still gives an easy way of
seeing which methods you requested to be inlined that were not.
The flag would display only functions marked with pragma(inline,
true).

On Monday, 24 February 2014 at 18:00:39 UTC, Kapps wrote:
> Perhaps something like a -vinline similar to -vtls? You don't
> need to be spammed repeatedly every time you build saying
> something isn't inlined, yet this still gives an easy way of
> seeing which methods you requested to be inlined that were not.
> The flag would display only functions marked with pragma(inline,
> true).

As I have already mentioned in this thread, there already does exist pull request to add flag to print inlining diagnostics. It can be re-used once merged.

On Monday, 24 February 2014 at 16:58:21 UTC, Manu wrote:
> For those interested, in my experience, the value of inlining is rarely
> related to eliminating the cost of the function call. call and ret have
> virtually no impact on performance on any architecture I've used.

It highly depends on the architecture you run on. X86 is
astonishingly good at this.

> The main value is that it eliminates stuffing around with parameter lists,
> and managing save registers. Also, some argument types can't pass in
> registers, which means they pass through memory, and memory access should
> be treated no differently from the hard drive in realtime code ;) .. The
> worst case is a write followed by an immediate read (non-register argument,
> or save register value); some architectures stall waiting for the full
> flush before they can read it back. It's called a Load-Hit-Store hazard,
> and it's the most expensive low level hazard short of an L2 miss.

All modern architecture (if I put aside PIC) that I know of have
a store buffer to avoid this.

Also, not inlining prevent the compiler to do constant
propagation, and as such, prevent the compiler from doing a lot
of optimizations.

> I agree that inline should be a hint (a STRONG hint, not like 'inline' in
> C, more like __force_inline, perhaps stronger), but I'd like it if I
> received a warning when it failed for whatever reason. I don't want it to
> stop compiling, but a nice notification that I should look into it, and the
> ability to disable/silence the warning if I can't/don't intend to.

Proposed semantic:
Inline unless for some reason you cannot. If you cannot, warn
about it.

Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> writes:

> On 2/23/14, 8:26 PM, Vladimir Panteleev wrote:
>> Thus, I think there should be "try to inline" (same as -inline) and
>> "always inline" (failure stops compilation).
>
> Sounds fair enough.

pragma(inline, false);
pragma(inline, true);
pragma(inline, force);  // inline or die

How is that?