On 02/11/2011 10:22 PM, Christopher Nicholson-Sauls wrote:
> 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

All of this is hardly related to the simple feature I initially asked for:

	string escString (string s) @tellmeifnotinlined {
	    s2 = s.replace("\n","\\n");
	    s2 = s.replace("\t","\\t");
            return s2;
        }
	void show (X x) {
	    // ... use escString ...
        }
==>
	Warning: function 'escString' in module 'foo' (line 123) was not inlined.
	(or else it was actually inlined)

Which (I guess) is not that a big deal since the compiler needs to decide anyway. I just wish to be informed of the result of the decision procedure, only in case of 'no'.

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

> All of this is hardly related to the simple feature I initially asked for:
>
> 	string escString (string s) @tellmeifnotinlined {
> 	    s2 = s.replace("\n","\\n");
> 	    s2 = s.replace("\t","\\t");
>              return s2;
>          }
> 	void show (X x) {
> 	    // ... use escString ...
>          }
> ==>
> 	Warning: function 'escString' in module 'foo' (line 123) was not inlined.
> 	(or else it was actually inlined)
>
> Which (I guess) is not that a big deal since the compiler needs to decide anyway. I just wish to be informed of the result of the decision procedure, only in case of 'no'.
>
> Denis

Guys, i don't know what are you trying or why you simply seem to avoid my reasoning on this, if you don't need this (and you all seem not use it) why are you trying to find solutions for the problems that doesn't affect you directly? :)

Unline a few of you said this is not a complex problem and actually it hasn't been complex in C++ either for again, practical purposes.

Standard C++ says:
For class/struct methods, compiler inlines things and it is aware of most of them wrappers so you don't need "inline" keyword there.
But still it does have this keyword as a hint to use other methods. This has never been enough and all major compilers now have forced inlines. (always_inline, __forceinline...)
What they do is forcing to compiler inline a function and if compiler won't do it it issues an error to state why.

All is needed is just i said in another post:
@inline // inline or issue and error why you won't.

- simple
- serves practical purposes rather than fiction
- it does no harm to anyone
- so easy to implement
- it is sometimes advanced but still something controllable

Now please what is wrong here someone enlighten me.

Thanks.

> 
> All of this is hardly related to the simple feature I initially asked for:
> 
>     string escString (string s) @tellmeifnotinlined {
>         s2 = s.replace("\n","\\n");
>         s2 = s.replace("\t","\\t");
>             return s2;
>         }
>     void show (X x) {
>         // ... use escString ...
>         }
> ==>
>     Warning: function 'escString' in module 'foo' (line 123) was not
> inlined.
>     (or else it was actually inlined)
> 
> Which (I guess) is not that a big deal since the compiler needs to decide anyway. I just wish to be informed of the result of the decision procedure, only in case of 'no'.
> 
> Denis

I could really go for that, myself.  Occasionally I've wanted such a beasty.  I really do think it makes more sense as a pragma() than an attribute unto itself, though.

-- Chris N-S

On 02/12/2011 10:46 AM, Christopher Nicholson-Sauls wrote:
>>
>> All of this is hardly related to the simple feature I initially asked for:
>>
>>      string escString (string s) @tellmeifnotinlined {
>>          s2 = s.replace("\n","\\n");
>>          s2 = s.replace("\t","\\t");
>>              return s2;
>>          }
>>      void show (X x) {
>>          // ... use escString ...
>>          }
>> ==>
>>      Warning: function 'escString' in module 'foo' (line 123) was not
>> inlined.
>>      (or else it was actually inlined)
>>
>> Which (I guess) is not that a big deal since the compiler needs to
>> decide anyway. I just wish to be informed of the result of the decision
>> procedure, only in case of 'no'.
>>
>> Denis
>
> I could really go for that, myself.  Occasionally I've wanted such a
> beasty.  I really do think it makes more sense as a pragma() than an
> attribute unto itself, though.

Agreed, since it's not a language feature properly speaking. Anyway...

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