https://issues.dlang.org/show_bug.cgi?id=15671

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> ---
The compiler is using a heuristic of "if the amount of code in a function is above a certain threshold, then it is not inlined." The idea is that the overhead of a function call becomes small when the size of the function is large. Where the code came from is irrelevant.

--

https://issues.dlang.org/show_bug.cgi?id=15671

--- Comment #2 from Steven Schveighoffer <schveiguy@yahoo.com> ---
First, to update the issue, you need a lot less uniform calls (probably the underlying uniform call is more code than it used to be), update longFunc to this:

void longFunc()
{
    version(good)
       x = uniform!int();
    x = uniform!int();
}

Second, the problem here is not the inliner heuristic. There is no reason that the compiler cannot change:

foo!longFunc();

into:

longFunc();
x = uniform!int();

In other words, inline foo, but NOT inline func (and all the stuff it calls).

The point of forced inlining is to change a common call situation into directly written code.

What this bug report is saying is that the inlining heuristic should take into account that an outer portion should be inlined even if all the underlying code cannot be.

If I change this to make longFunc opaque, it works:

pragma(mangle, "longFunc")
void longFunc_impl()
{
    x = uniform!int();
}


void foo(alias func)()
{
    pragma(inline, true);
    func();
    x = uniform!int();
}

extern(C) void longFunc();

void main()
{
    foo!longFunc();
}

This is the behavior I would expect -- inline *this function* even if you can't inline the calls it makes.

--

https://issues.dlang.org/show_bug.cgi?id=15671

Tobias Pankrath <tobias@pankrath.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tobias@pankrath.net

--- Comment #3 from Tobias Pankrath <tobias@pankrath.net> ---
LLVM has flatten [1] next to inline. I think what you want at this point is the behaviour of flatten.

[1] https://clang.llvm.org/docs/AttributeReference.html#flatten

--

https://issues.dlang.org/show_bug.cgi?id=15671

--- Comment #4 from Walter Bright <bugzilla@digitalmars.com> ---
(In reply to Steven Schveighoffer from comment #2)
> [...]

I'm sorry, I find your post to be completely confusing.

--

https://issues.dlang.org/show_bug.cgi?id=15671

Stanislav Blinov <stanislav.blinov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stanislav.blinov@gmail.com

--- Comment #5 from Stanislav Blinov <stanislav.blinov@gmail.com> ---
(In reply to Walter Bright from comment #1)
> The compiler is using a heuristic of "if the amount of code in a function is above a certain threshold, then it is not inlined." The idea is that the overhead of a function call becomes small when the size of the function is large. Where the code came from is irrelevant.

void foo(alias func)()
{
    pragma(inline, true);
    func();
    x = uniform!int();
}

The "amount of code" in `foo` (which is explicitly marked by a pragma) is two function calls and a store. After inlining,  the

void main()
{
    foo!longFunc();
}

should become, at the very least

void main()
{
    longFunc();
    x = uniform!int();
}

Yet it fails, presumably because the compiler also attempts to inline `longFunc` and/or `uniform` in `foo` before inlining `foo` itself.

--

https://issues.dlang.org/show_bug.cgi?id=15671

--- Comment #6 from Steven Schveighoffer <schveiguy@yahoo.com> ---
Yes, Stanislav's description is correct.

The problem with the way pragma(inline) is implemented today is that it's very brittle if you are depending on functions that might change the heuristic in the future.

Consider a function like:

int foo(int val)
{
   // a bunch of complicated code.
   ...
}

In normal code, I enable inlining and whether the compiler inlines this or not, I don't care. Now, it turns out that a very frequent use of foo among users is:


auto x = someString.length ? foo(someString.to!int) : 0;

So I want to capture that as a wrapping function:

int fooStr(string val)
{
   import std.conv : to;
   return val.length ? foo(val.to!int) : 0;
}

But I don't want to change the performance of the original code, so I want the compiler to inline fooStr. I still don't care and want to leave it up to the compiler whether foo itself can be inlined. I just want to provide a nice way to avoid having to import std.conv, and write that conditional call every time. I don't care if foo is inlined, but I DO want fooStr to be inlined.

Without this functionality I'm not exactly sure why pragma(inline) even exists.

--

https://issues.dlang.org/show_bug.cgi?id=15671

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--

https://issues.dlang.org/show_bug.cgi?id=15671

--- Comment #7 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dmd/issues/19098

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB

--