Optional ModuleInfo (Part 2): Backend Optimizations

[JinShil]

This pull request is a follow up to #7395 and the rationale for this change is basically the same.

If ModuleInfo isn't declared in the runtime, there's no reason for the compiler (1) emit an error and (2) generate object code for it. PR #7395 took care of (1) and this PR takes care of (2). That is, prior to this PR, if ModuleInfo was not declared in the runtime, the backend still generated __start_minfo, __stop_minfo, and friends.

To make this work, the betterC backend config flag is split into its 3 component parts. That way the useExceptions flag can be used to turn on/off EH code generation, and the useModuleInfo flag can be used to turn on/off module info code generation independently. The useModuleInfo config flag is set with params.useModuleInfo && Module.moduleinfo. -betteC functionality still works the same, but now there's a little more fine tuning that can be done by what is declared or not declared in the runtime.

Benefits

• Resulting binaries are smaller
• Fewer useless stubs are required to generate a minimal runtime
• No more linker errors for the aforementioned stubs

This will be of interest to users wishing to incrementally or partially port D to new platforms, users hoping to target resource constrained platforms, and users wishing to use D as a library from other languages without druntime.

If this PR is merged, I should be able to do one more followup that can get an empty main program down to 56 bytes with or without the -betterC flag.

[dlang-bot]

Thanks for your pull request, @JinShil!

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.

[wilzbach]

FYI: the auto-tester changes are unrelated, see braddr/d-tester#66

[jpf91]

Nice work! Do you plan opening similar pull requests for GDC?

[JinShil]

Nice work! Do you plan opening similar pull requests for GDC?

Much of my motivation for doing this work is so I can eventually use D this way with GDC and ARM Cortex-M microcontrollers. However, I don't know anything about the differences between DMD and GDC. I was going to wait for you and @ibuclaw to begin merging the 2.079 frontend with GDC, try it out, and see what needs to be done (hoping you'll get in touch with me when the time comes).

If there's anything I can do to facilitate getting this and some of my other DMD PRs into GDC, please let me know. I still have a few more things I'd like to do to DMD to make minimal-runtime programming in D more polished, but everything I'm doing here in DMD is so I can eventually use these features in GDC.

[ibuclaw]

Nice work! Do you plan opening similar pull requests for GDC?

Adding an extra check to Module::moduleinfo for its existence would really just be an extra formality (but a one-line change in gcc/d/modules.cc). There already exists an -fno-moduleinfo switch for a long time now, looks like this change just makes it so that is no longer required in for a minilibd-style runtime library.

I was going to wait for you and @ibuclaw to begin merging the 2.079 frontend with GDC, try it out, and see what needs to be done (hoping you'll get in touch with me when the time comes).

I don't think that will happen for a while. The splitting of betterC into granular codegen options should be backported, however. Also the time is nigh for fast compile-times, have pinged you in the relevant PR.

[JinShil]

The splitting of betterC into granular codegen options should be backported

I'm not sure what you mean by that. Are you saying we should expose the 3 options (useTypeInfo, useExceptions, useModuleInfo) as separate switches in DMD?

[ibuclaw]

Backport means gdc. Otherwise I would have said upstream. ☺️

[jpf91]

@JinShil ok. It's indeed a good idea to implement all this stuff in DMD upstream first, then add the remaining parts in GDC 👍

When we talk about backporting in the GDC context we usually mean that instead of waiting for the next DMD frontend merge, we instead selectively apply some changes to GDC (with an older frontend version), thus backporting the changes. We usually do this for very important features, architecture support, etc...