Remove the dmd front-end inliner and related code

[ibuclaw]

(See also related: #16170 and #16171)

As discussed in last DLF meeting.

• gdc and ldc both ignore the front-end inliner, only doing inlining in the backend.
• dmd has a back-end inliner, but it is incomplete
• It is generally accepted that dmd the compiler to use for rapid prototyping, so its main focus should be on getting compile-times down, not producing more optimal programs.

By disabling the front-end inliner, building Phobos with -O -release -inline gets cut down from 40s -> 10s on my machine.

Parts of the front-end inliner is still kept around for inlining default arguments (inlineCopy).

• gdc uses arg.copy() and is happy with it
• dmd apparently can't use arg.copy() because of https://issues.dlang.org/show_bug.cgi?id=2935
• ldc doesn't appear to deviate from dmd.

Could attempt removing inlineCopy again if this gets pulled (see also #14214 and #14309)

[dlang-bot]

Thanks for your pull request, @ibuclaw!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#16173"

[ibuclaw]

It is generally accepted that dmd the compiler to use for rapid prototyping, so its main focus should be on getting compile-times down, not producing more optimal programs.

inlining is still useful in debug builds in math intensive applications, like games for example

i personally oppose removing the ability for DMD to be inline things when asked for it, with the pragma for example, i hope that one mechanic stays

DMD has a backend inliner, it just isn't currently used for non-optimised builds

(See also related: #16170 and #16171)

[thewilsonator]

Need to update frontend.h

diff --git a/home/circleci/dmd/compiler/src/dmd/frontend.h b/home/circleci/dmd/generated/linux/release/64/frontend.h
index d29bccf2aa..6536228d62 100644
--- a/home/circleci/dmd/compiler/src/dmd/frontend.h
+++ b/home/circleci/dmd/generated/linux/release/64/frontend.h
@@ -411,9 +411,7 @@ enum class PASS : uint8_t
     semantic2done = 4u,
     semantic3 = 5u,
     semantic3done = 6u,
-    inline_ = 7u,
-    inlinedone = 8u,
-    obj = 9u,
+    obj = 7u,
 };

[ibuclaw]

It looks like this is does not play well with #16170 - so I've reverted it in #16176.

[ibuclaw]

It is generally accepted that dmd the compiler to use for rapid prototyping, so its main focus should be on getting compile-times down, not producing more optimal programs.

inlining is still useful in debug builds in math intensive applications, like games for example
i personally oppose removing the ability for DMD to be inline things when asked for it, with the pragma for example, i hope that one mechanic stays

DMD has a backend inliner, it just isn't currently used for non-optimised builds

(See also related: #16170 and #16171)

it does, dmd -debug -inline this works, and is enough to give a perf boost

Right, so #16171 will have you covered then.

[thewilsonator]

this appears to segfault on AuburnSounds/interl-intrinsics

[thewilsonator]

cc @WalterBright about the backend inline segfault hitting this assert on build kite AuburnSounds/interl-intrinsics

[thewilsonator]

merged dependant PR

[WalterBright]

I'd like to get rid of the front line inliner as much as anyone.

But I'd like to wait on this until the dmd backend inliner is more effective. Inlining has a huge effect on performance, so much so that some programs are unusable without inlining.