http://wiki.dlang.org/DIP56

Manu has needed always inlining, and I've needed never inlining. This DIP proposes a simple solution.

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.

Is this a front-end thing or something specific to DMD?  I'm wondering because I'd like something like this for GDC and LCD when targeting ARM microcontrollers.  The inline keyword makes quite a significant performance improvement in one of my current C++ projects, and I anticipate the same result when I convert it to D.

Any chance of adding a "optimize, true/false" pragma also to get around the lack of a volatile keyword? (Just a question, I don't mean to hijack this thread and turn into another volatile keyword debate).

Mike

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?

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.

yay, all for it! The DIP should probably specify what happens if inlining fails, i.e. generate a compilation error.

Could we consider adding "flatten" in the same dip?

quote from gcc
"Flatten
Generally, inlining into a function is limited. For a function marked with this attribute, every call inside this function is inlined, if possible. Whether the function itself is considered for inlining depends on its size and the current inlining parameters. "

On 2/23/2014 4:21 AM, Mike wrote:
> Is this a front-end thing or something specific to DMD?  I'm wondering because
> I'd like something like this for GDC and LCD when targeting ARM
> microcontrollers.  The inline keyword makes quite a significant performance
> improvement in one of my current C++ projects, and I anticipate the same result
> when I convert it to D.

It's a hint to the compiler - the compiler is allowed to ignore it if it doesn't support it.


> Any chance of adding a "optimize, true/false" pragma also to get around the lack
> of a volatile keyword? (Just a question, I don't mean to hijack this thread and
> turn into another volatile keyword debate).

Please start another thread with your proposal.

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.

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

Seems like a solution would be preferred where this can be used for multiple functions. A UDA/@property of some sort.

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.

-- 
Dmitry Olshansky

23-Feb-2014 16:25, Tove пишет:
> 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.
>
> yay, all for it! The DIP should probably specify what happens if
> inlining fails, i.e. generate a compilation error.
>
> Could we consider adding "flatten" in the same dip?
>
> quote from gcc
> "Flatten
> Generally, inlining into a function is limited. For a function marked
> with this attribute, every call inside this function is inlined, if
> possible. Whether the function itself is considered for inlining depends
> on its size and the current inlining parameters. "

Yes, please.

-- 
Dmitry Olshansky

On 2/23/2014 4:25 AM, Benjamin Thaut wrote:
> Why a pragma? Can't we use a UDA and give it some special meaning inside the
> compiler?

This shouldn't be an attribute, it's a hint to the compiler optimizer. Pragma is ideally suited to that.

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