[JinShil]

Currently the compiler does not attempt to do any inlining whatsoever regardless of any pragma(inline, true) annotations. It will only attempt to inline functions if the compiler is invoked with the -inline flag.

This PR changes the behavior of pragma(inline, true) so the compiler always attempts to inline a function annotated with pragma(inline, true) regardless of whether or not the compiler is invoked with the -inline` flag. All other behaviors remain the same.

[thewilsonator]

A little more description would be useful...

Also cc @TurkeyMan

[JinShil]

Requires dlang/phobos#7059

[thewilsonator]

see also #7690 (Still haven't been able to figure out why that one fails on Ocean yet).

[WalterBright]

The reason this is not done is because always doing an inline scan slows down the compiler.

[WalterBright]

Doing this in away that doesn't always require an inline scan is a much more difficult fix than this is.

[JinShil]

The reason this is not done is because always doing an inline scan slows down the compiler.

This claim does make sense, but I'm not seeing any significant difference. There are other things in a build that contribute much more to the time than this.

Here's my data compiling Phobos:

With this PR:

time make -f posix.mak

# Take 1
real	0m33.876s
user	0m31.966s
sys	0m1.602s

# Take 2
real	0m40.413s
user	0m38.207s
sys	0m1.830s

Without this PR:

time make -f posix.mak

# Take 1
real	0m47.470s
user	0m44.997s
sys	0m2.032s

# Take 2
real	0m33.681s
user	0m31.786s
sys	0m1.587s

Also most of the inline scanning is gated here

dmd/src/dmd/inline.d

Lines 1691 to 1694 in e9ef759

	if (fd.inlining == PINLINE.default_ && !global.params.useInline)
	{
	return false;
	}

which probably explains the insignificant change in compile times. That gate means only those functions attributed with pragma(inline, true) are subject to the full scan.

Doing this in away that doesn't always require an inline scan is a much more difficult fix than this is.

Then I suggest merging this and adding a bug report to implement the more difficult fix as an improvement.

[WalterBright]

1. The way you're doing timings is not accurate enough.

2. "insignificant" costs have a way of adding up. DMD has been steadily slowing down with all these insignificant costs. Not only does it have to do the scanning, it has to do semantic analysis of every function called - a task it currently skips.

Then I suggest merging this and adding a bug report to implement the more difficult fix as an improvement.

No, because the bug is not that significant in that its effect is minor, but this PR negatively affects everyone. There are too many higher priority things I need to work on.

[JinShil]

Here are timings for just the compiling stage of the phobos build:

Without this PR:

real	0m15.303s
user	0m14.152s
sys	0m0.848s

With this PR:

real	0m15.461s
user	0m14.332s
sys	0m0.855s

[JinShil]

No, because the bug is not that significant in that its effect is minor, but this PR negatively affects everyone.

It doesn't look like it negatively affects anyone, and would positively affect a few people including myself.

[WalterBright]

A 1% slowdown is significant.

[JinShil]

Would you be willing to advise me with any specifics to improve this PR to your satisfaction?

[WalterBright]

I don't really know of a good way to do it that isn't slow, or I'd have done it already.