On 23 February 2014 14:19, Tove <tove@fransson.se> wrote:
> 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));

WAT!

On Sunday, 23 February 2014 at 13:07:27 UTC, Dmitry Olshansky wrote:
> 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.

That is most likely when I would make use of the concept too. And a message from the compiler in its output telling me when such an inline request failed would be helpful.

Joseph

On Sunday, 23 February 2014 at 12:50:58 UTC, Walter Bright wrote:
> On 2/23/2014 4:38 AM, Dmitry Olshansky wrote:
>> Why pragma?
>
> Answered in another post.
>
>
>> Also how exactly it is supposed to work:
>
> T func(args)
> {
>     ...
>     pragma(inline, true);
>     ...
> }
>
>
>> How to return to normal state then?
>
> Not necessary when it's inside a function.
>
>
>> I'd strongly favor introducing a compiler-hint family of UDAs and
>> force_inline/force_notinline as first among many.
>
> I don't see an advantage of that over pragma. It also seems like something that should be inside a function, not outside. (After all, a function with no body cannot be inlined.)

Thanks for the code example. That helped me better understand what is being proposed.

I like the idea of using pragma since it is built specifically for the purpose of sending information to the compiler from code. Also, I like not having to add another keyword to a function definition. Especially since I already have "@safe pure nothrow" in as many places as possible, for inline-able functions I'd prefer to not have to add "inline" to that list. Using a pragma would mean it could be implemented right away without worrying about breaking any existing code. The proposal also satisfies the needs of both parties. Especially since D is a flexible language it would be nice to give such ability to customize code generation to the programmer.

Given the above I think this is a good idea.

Joseph

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.
> Part of the reason for forced inline is always inlining some core primitives, even in debug builds.

Optional recommendation for inlining already exists - it is current default. This pragma needs to result in compile-time error if used where inlining is not possible to be any useful.

Other than that, looks fine.

On Sunday, 23 February 2014 at 12:25:20 UTC, Benjamin Thaut wrote:
> Am 23.02.2014 13:07, schrieb 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 a pragma? Can't we use a UDA and give it some special meaning inside the compiler?

+1
I would also prefer an attribute which can be used as label.

----
@inline(true):
// ...
@inline(false):
// ...
@inline(default):
----

On 2/23/2014 5:06 AM, Joseph Rushton Wakeling wrote:
> 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?

I'll add:

    pragma(inline);

meaning revert to default behavior.


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

The last one wins.

On Sunday, 23 February 2014 at 20:29:19 UTC, Walter Bright wrote:
> I'll add:
>
>     pragma(inline);

That's just going to confuse people, because they'll think *this* forces inlining.

I'd prefer 3 separate states. pragma(inline), pragma(no_inline), and pragma(default_inline) or something like that.

On 2/23/2014 5:01 AM, Vladimir Panteleev wrote:
> 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.

I think it would be a porting nuisance to error out when the compiler can't inline. The user would then fix it by versioning out for that compiler, and then the user is back to the same state as it being a recommendation.

Generally, when I optimize at that level, I have a window open on the assembler output of the compiler and I go back and forth on the source code until I get the shape of the assembler I need. Having compiler messages wouldn't be very helpful.

On 2/23/2014 5:07 AM, Dmitry Olshansky wrote:
> Part of the reason for forced inline is always inlining some core primitives,
> even in debug builds.

Right - and if the compiler won't do it, how does the error message help?

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

By the time you get to the point of checking on inlining, you're already looking at the assembler output, because the function is on the top of the profile of time wasters, and that's how you take it to the next level of performance.

The trouble with an error message, is what (as the user) can you do about it?

On 2/23/2014 11:04 AM, Dicebot wrote:
> Optional recommendation for inlining already exists - it is current default.

That is not the point of the pragma. The point of always inlining is (as Manu explained) some functions need to be inlined even in debug mode, as the code would otherwise be too slow to even debug.