[Don't merge yet] Internalize everything but _Dmain when emitting a -singleobj executable. #483

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
3 participants
Owner

klickverbot commented Oct 2, 2013

This is just a first draft; there are certainly cases
where this still breaks (e.g. naked inline asm).

The general direction looks promising, though: Building a
fully optimized Phobos "Hello World" is noticably faster
with the internalizing enabled (0.7s vs 1s) on my machine.

Enabling the pass by default on -O4 and above is more of
a cute idea (to finally do the flag description justice)
than a serious proposal.

Don't merge yet, this is just up for discussion.

@klickverbot klickverbot Internalize everything but _Dmain when emitting a -singleobj executable.
This is just a first draft; there are certainly cases
where this still breaks (e.g. naked inline asm).

The general direction looks promising, though: Building a
fully optimized Phobos "Hello World" is noticably faster
with the internalizing enabled (0.7s vs 1s) on my machine.

Enabling the pass by default on -O4 and above is more of
a cute idea (to finally do the flag description justice)
than a serious proposal.
34a98f7
Owner

klickverbot commented Oct 4, 2013

@redstar, @AlexeyProkhin: What do you think about shipping something like this eventually (as mentioned above, the current state has a ton of problems)? This really helps to bring compile times down for the case where users build a whole project at once (e.g. using rdmd --compiler=ldmd2 <…>), as all the unneeded functions can be pruned after inlining. It also enables some more aggressive optimizations, yielding to fairly nice speedups in some benchmarks.

Ideally, we could get this stable enough to run on -O2 and above by default (i.e., where inlining is enabled).

Also, we should probably come up with a good strategy to implement LTO in a way so that druntime/Phobos can take advantage of it (cf. all the inlining-related performance discussions on the NG). BUILD_BC_LIBS is a start, but it has to be used manually right now.

Shared library support could be an additional challenge once it arrives in 2.064.

Owner

klickverbot commented Oct 4, 2013

(Hm, I guess libraries depending on symbols from the executable might be an issue, though. Just about time we actually fix export in D.)

Member

AlexeyProkhin commented Oct 5, 2013

What do you think about shipping something like this eventually (as mentioned above, the current state has a ton of problems)?

If it improves compile time, why not? Provided, of course, the ton of problems is fixed.

Owner

redstar commented Oct 8, 2013

I see no problems with experimental features. We should only make sure that our users know this, too. (E.g. the text of the -help option should be changed; it can be mentioned in release notes or wiki pages; etc.)

Owner

klickverbot commented Oct 8, 2013

Ideally, we want to enable this at -O2 and above at some point.

I guess the best way would be to first add an experimental command line switch, encourage users to test it, and eventually invert its meaning (i.e. enable internalizing by default, but leave a workaround to be used for applications that actually depend on symbols being visible, which might happen, at least until export is fixed and implemented).

Owner

klickverbot commented Aug 29, 2015

Need to think more about LTO. Might happen next week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment