belkadan
commented
6 years ago Note: No need for -Xfrontend here; the driver accepts -num-threads directly.
Open aschwaighofer opened 6 years ago
belkadan
commented
6 years ago Note: No need for -Xfrontend here; the driver accepts -num-threads directly.
Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 0 | |Component/s | Compiler | |Labels | Bug, IRGen | |Assignee | None | |Priority | Medium | md5: 780a2f361672efbe0a10442744350e1fIssue Description:
When we run the swift compiler in multithreaded compilation (-Xfrontend -num-threads -Xfrontend 1..n) mode we split up a swift module into several LLVM modules (one per source file). We put a definition into a LLVM module based on the swift source file the definition stemmed from.
This split can inhibit LLVM passes that reduce code size based on global defintion visibility e.g. the merge functions pass.
Experiments have shown that we loose (significant) code size reducing opportunity because of this.
We don't want to give up on multi-threaded compilation so we should investigate how to get back most of this code size saving opportunity we loose this way.
We should look into better partioning into LLVM modules:
be cleverer where we put definitions e.g.
emit all value witnesses, thunks, etc. into the same LLVM module
emit all specializations of stdlib functions into the same LLVM modules (if we don't do so already)
introduce a reasonable maximum number of LLVM modules
Experiment running the swift source compatibility suite with -num-threads 0 to illustrate what we win with disabling num-threads: