Jonathan M Davis Wrote:

> On Thursday 10 February 2011 22:35:34 Walter Bright wrote:
> > Stewart Gordon wrote:
> > > On 09/02/2011 12:14, spir wrote:
> > >> Hello,
> > >> 
> > >> Walter states that inline annotations are useless, since programmers
> > >> cannot generally know
> > >> which function /should/ be inlined --depending on a variety of
> > >> factors, inlining may in
> > >> fact be counter-productive.
> > > 
> > > <snip>
> > > 
> > > I hate not being able to force functions to be inline.  A consequence is that you can't fully interface certain APIs without an extra .lib over what would be needed in C(++).
> > 
> > You cannot force inlining in C(++) either. The inline keyword is only a
> > suggestion.
> 
> True. However, IIRC -O3 in gcc forces inlining, so in some cases you _can_ force it (though that's obviously compiler-specific), but forcing inlining with -O3 does it for _everything_, so it's not exactly precision instrument.
> 
> Regardless, I would _hope_ that the compiler would be smart enough to make intelligent choices about inlining. That's probably one of those areas that can always be improved however.


I also think that this decision should be left to the compiler.

The inline keyword was deemed useful for the same reason that symbols had to be declared before their use (causing the C/C++ header hell) -- it's easier to implement such a compiler.

On 02/11/2011 09:33 AM, Jim wrote:
>> Regardless, I would _hope_ that the compiler would be smart enough to make
>> >  intelligent choices about inlining. That's probably one of those areas that can
>> >  always be improved however.
>
> I also think that this decision should be left to the compiler.
>
> The inline keyword was deemed useful for the same reason that symbols had to be declared before their use (causing the C/C++ header hell) -- it's easier to implement such a compiler.

Agreed; but what about having the compiler tell you, on demand, "func 'f' at line #l in module 'm' was not inlined" ?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

spir Wrote:

> On 02/11/2011 09:33 AM, Jim wrote:
> >> Regardless, I would _hope_ that the compiler would be smart enough to make
> >> >  intelligent choices about inlining. That's probably one of those areas that can
> >> >  always be improved however.
> >
> > I also think that this decision should be left to the compiler.
> >
> > The inline keyword was deemed useful for the same reason that symbols had to be declared before their use (causing the C/C++ header hell) -- it's easier to implement such a compiler.
> 
> Agreed; but what about having the compiler tell you, on demand, "func 'f' at line #l in module 'm' was not inlined" ?

I rarely need to go that low-level. My hope is that the compiler will sort this out in the end. Give it some time, or effort to have these optimizations implemented in the compiler.

Jim:

> I rarely need to go that low-level.

Two times I have had D1 code that was too much slow compared to equivalent C code. After profiling and some changes I have understood that the cause was an important missing inline. With a list of the inlined functions (as done by CommonLisp some compilers, see the enhancement request in Bugzilla), this search becomes quicker.


> My hope is that the compiler will sort this out in the end. Give it some time, or effort to have these optimizations implemented in the compiler.

The LLVM back-end of LDC is able to inline much more, but even here a list of inlined/not inlined functions helps. D is almost a system language, so sometimes you need to go lower level (or you just need a program that's not too much slow).

Bye,
bearophile

On 02/11/2011 07:08 PM, bearophile wrote:
> Jim:
>
>> I rarely need to go that low-level.
>
> Two times I have had D1 code that was too much slow compared to equivalent C code. After profiling and some changes I have understood that the cause was an important missing inline. With a list of the inlined functions (as done by CommonLisp some compilers, see the enhancement request in Bugzilla), this search becomes quicker.
>
>
>> My hope is that the compiler will sort this out in the end. Give it some time, or effort to have these optimizations implemented in the compiler.
>
> The LLVM back-end of LDC is able to inline much more, but even here a list of inlined/not inlined functions helps. D is almost a system language, so sometimes you need to go lower level (or you just need a program that's not too much slow).

To me the relevant aspect is not that much practical effect, but understanding how/why/what is inlined by (hopefully good) compilers. Learning about that, even if not much put in practice (I don't intend to write the next big language's compiler ;-) can only improve coding skills and, say... help and stop shooting in the dark.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

bearophile Wrote:
> The LLVM back-end of LDC is able to inline much more, but even here a list of inlined/not inlined functions helps. D is almost a system language, so sometimes you need to go lower level (or you just need a program that's not too much slow).


If forced inlining is to be supported I think it would be good idea to also let the _caller_ decide whether to inline a function. The compiler could simply find the function definition, perhaps parameterize it, and then insert it. Should it not be able to inline almost any function if asked to?

Jim Wrote:

> bearophile Wrote:
> > The LLVM back-end of LDC is able to inline much more, but even here a list of inlined/not inlined functions helps. D is almost a system language, so sometimes you need to go lower level (or you just need a program that's not too much slow).
> 
> 
> If forced inlining is to be supported I think it would be good idea to also let the _caller_ decide whether to inline a function. The compiler could simply find the function definition, perhaps parameterize it, and then insert it. Should it not be able to inline almost any function if asked to?


Just had another idea..
A function would know statically whether it has been inlined or not. If inlined it could choose to propagate this attribute to any of its own callees. Not sure it would be useful though, just thinking aloud..

Jim:

> If forced inlining is to be supported

spir was asking for a list of functions that the compiled has inlined, not for a forced inlining functionality.

Bye,
bearophile

On 02/11/11 14:26, Jim wrote:
> Jim Wrote:
> 
>> bearophile Wrote:
>>> The LLVM back-end of LDC is able to inline much more, but even here a list of inlined/not inlined functions helps. D is almost a system language, so sometimes you need to go lower level (or you just need a program that's not too much slow).
>>
>>
>> If forced inlining is to be supported I think it would be good idea to also let the _caller_ decide whether to inline a function. The compiler could simply find the function definition, perhaps parameterize it, and then insert it. Should it not be able to inline almost any function if asked to?
> 
> 
> Just had another idea..
> A function would know statically whether it has been inlined or not. If inlined it could choose to propagate this attribute to any of its own callees. Not sure it would be useful though, just thinking aloud..

And at this point what once seemed a simple thing starts to show its complexity teeth.  Suddenly there are all this adjunct features to be provided in order to make it properly useful.

Don't get me wrong, I'd actually like having all this... but I'm not sure of the cost in compiler complexity (and likely slowdown) and language bloat.

But, here's some notions:

== I really want foo() to be inlined, if even remotely possible! ==

pragma( inline )
int foo () { ... }

== I'll be calling foo(), and I'd like it inlined if possible ==

int bar () {
  pragma( inline, foo );
  // ...
  auto x = foo();
}

== I'm foo(), and I'd like to know if I am being inlined ==

int foo () {
  pragma( inline, true ) {
    // inline code
  }
  pragma( inline, false ) {
    // ordinary code
  }
}

-- or if we ever get that 'meta' namespace some of us want --

int foo () {
  static if ( meta.inlined ) {
    // inline code
  }
  else {
    // ordinary code
  }
}

My chief complaint with my own notions is that 'pragma(inline' ends up with three different forms.  This just isn't typical of a pragma.

-- Chris N-S

On 02/11/2011 09:49 PM, bearophile wrote:
> Jim:
>
>> If forced inlining is to be supported
>
> spir was asking for a list of functions that the compiled has inlined, not for a forced inlining functionality.

You are (nearly) right, Bearophile. More precisely, I rather wish @inline on a given func to output a compiler message if said func is *not* inlined, due to some criterion the compiler uses to decide; at best, some hint about said criterion.
I certainly do /not/ ask for forced inlining. (But others take the thread and speak of what they wish...)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com