Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the dmd front-end inliner and related code #16173

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ibuclaw
Copy link
Member

@ibuclaw ibuclaw commented Feb 10, 2024

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

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

@dlang-bot
Copy link
Contributor

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 ibuclaw added the Backend glue code, optimizer, code generation label Feb 10, 2024
@ryuukk
Copy link
Contributor

ryuukk commented Feb 10, 2024

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

@ibuclaw
Copy link
Member Author

ibuclaw commented Feb 11, 2024

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)

Copy link
Contributor

@thewilsonator thewilsonator left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ibuclaw force-pushed the dmd_rm_fe_inline branch 3 times, most recently from 3a2a324 to b5fc2a8 Compare February 11, 2024 09:00
@ibuclaw
Copy link
Member Author

ibuclaw commented Feb 11, 2024

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

@ryuukk
Copy link
Contributor

ryuukk commented Feb 11, 2024

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

@ibuclaw
Copy link
Member Author

ibuclaw commented Feb 11, 2024

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
Copy link
Contributor

this appears to segfault on AuburnSounds/interl-intrinsics

@thewilsonator
Copy link
Contributor

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

@thewilsonator
Copy link
Contributor

merged dependant PR

@WalterBright
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Backend glue code, optimizer, code generation Needs Rebase stalled
Projects
None yet
5 participants