[SR-6329] [code size] IRGen's splitting into several LLVM modules (num-threads > 0) inhibits redundant code elimination #48879
Comments
|
Note: No need for -Xfrontend here; the driver accepts -num-threads directly. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Additional Detail from JIRA
md5: 780a2f361672efbe0a10442744350e1f
Issue 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:
The text was updated successfully, but these errors were encountered: