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 :)

On 2/23/2014 4:31 AM, Andrej Mitrovic wrote:
> What if you want to mark a series of functions to be inlined? E.g. in an entire
> module:
>
> -----
> module fast;
>
> // ??
> pragma(inline, true):
>
> Vec vecSum();
> Vec vecMul();
> -----

That can work because pragmas can have blocks associated with them.

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);
}

:-)

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.

On Sunday, 23 February 2014 at 12:57:00 UTC, Walter Bright 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.

I think there should be some way to force the compiler to inline a function. As a bonus, the error message can tell the programmer why the function could not be inlined, allowing them to make the necessary adjustments.

Different compilers will have different inlining capabilities, however at the point where programmers are forcing inlining on or off, they are already micro-optimizing at a level which implies dependency on particular compiler implementations.

Am 23.02.2014 13:38, schrieb Dmitry Olshansky:
> 23-Feb-2014 16:07, Walter Bright пОшет:
>> http://wiki.dlang.org/DIP56
>>
>> Manu has needed always inlining, and I've needed never inlining. This
>> DIP proposes a simple solution.
>
> Why pragma? Also how exactly it is supposed to work:
>
> pragma(inline, true);
> ... //every declaration that follows is forcibly inlined?
> pragma(inline, false);
> ... //every declaration that follows is forcibly NOT inlined?
>
> How to return to normal state then? I think pragma is not attached to
> declaration.
>
> I'd strongly favor introducing a compiler-hint family of UDAs and
> force_inline/force_notinline as first among many.

yea it feels strange - like naked in inline asm
its a scope changer - that sits inside the scope it changes???

like writing public methods by putting public inside of the method - and public is also compiler relevant for the generated interface

and aligne is also not a pragma - and still changes codegeneration

its a function-(compile-)attribute but that does not mean it have to
be a pragma

btw: is the pragma way just easier to implement - or else i don't understand why this is handle so special?

On 23/02/2014 13:07, 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.

Sounds good in principle.  So, if I understand right, a pragma(inline, true) anywhere inside a function adds a compiler hint to always inline this function, while with false it's a hint to _never_ do so, and no pragma at all gives the usual compiler-decides situation?

Question: what happens if someone is daft enough to put both true and false inside the same function?

In any case, could you possibly provide a slightly more detailed code example with accompanying explanation of what the intended results are?

23-Feb-2014 16:57, Walter Bright пишет:
> 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.

It's going to be near useless if it doesn't make sure inlining happened.
Part of the reason for forced inline is always inlining some core primitives, even in debug builds.

The other point is what Vladimir mentioned - we already doing micro-optimization, hence it better error out then turn a blind eye on our tinkering. I wouldn't not like to ever have to get down and look at ASM for every function just to make sure it was inlined.

-- 
Dmitry Olshansky

On Sunday, 23 February 2014 at 13:07:27 UTC, Dmitry Olshansky wrote:
> It's going to be near useless if it doesn't make sure inlining happened.
I completely agree.

On Sunday, 23 February 2014 at 12:57:00 UTC, Walter Bright 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.

Would assert be feasible or difficult to implement with the current compiler design?

static assert(pragma(inline, true));