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
generate code for modules in DFO #16260
base: master
Are you sure you want to change the base?
Conversation
Thanks for your pull request, @WalterBright! Bugzilla referencesYour 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 locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub run digger -- build "master + dmd#16260" |
that is what link time optimisation is for. |
af3d53b
to
007f11f
Compare
@thewilsonator cheaters! :-) |
007f11f
to
af6eb62
Compare
@WalterBright there is no cross-module inlining in single-module compilation. There are a couple tricks to help it though. For example, |
af6eb62
to
862d968
Compare
I'm so tired of utterly useless error messages like this:
after a thousand lines of useless information. |
687ccef
to
edfb65f
Compare
For example,
what is that coming from? I try:
from The purpose of a test suite is not just to test things. The purpose is to make it easy to find where the problem is. Our test suite makes that a miserable and extremely time-consuming experience. We wouldn't accept such error diagnostics from the compiler, why do we accept it from the test suite? |
edfb65f
to
b687c71
Compare
@WalterBright I don't know whether you fixed the error or not, but I'm not seeing the error you are mentioning. I see that Azure is failing 2 runnable tests [1]:
There's also a bunch of buildkite projects failing, but I can't tell id they're related or not. |
@RazvanN7 thanks I'll check into these errors. |
The backend inliner relies on the code for functions to be inlined to be already generated. To that end, the modules presented to the code generator should be presented in depth-first-order to maximize the possibilities for inlining.
It still won't be able to inline functions for which code is not generated, as modules not listed on the command line. This seems to be a costly to overcome problem. Does gdc or ldc resolve it?
It also won't be able to inline functions that appear later in the source file than the function that wants to inline them. The functions in a module would also have to be in DFO order.