[PATCH] D52193: RFC: [clang] Multithreaded compilation support -- NOT FOR SUBMIT

aganea added a comment. Hi @tycho ! Sorry for not getting back earlier. I implemented an alternate approach last year, which proved to be better (in terms of build times) than what I proposed in this demo patch. That is, using a thread pool instead of the process pool as implemented here. This m

[PATCH] D52193: RFC: [clang] Multithreaded compilation support -- NOT FOR SUBMIT

tycho added a comment. I did some local work to make this build and pass almost all tests on Linux as well, not to make use of the multi-process features but just to avoid having a separate "for Windows only" branch, and to ensure tests pass across platforms. Unfortunately my change is not at a

[PATCH] D52193: RFC: [clang] Multithreaded compilation support -- NOT FOR SUBMIT

tycho added a comment. OK, those two problems were actually easy enough to fix. diff --git a/lib/Driver/Driver.cpp b/lib/Driver/Driver.cpp index 2f98cf9e04..93e974842f 100644 --- a/lib/Driver/Driver.cpp +++ b/lib/Driver/Driver.cpp @@ -3241,8 +3241,8 @@ void Driver::BuildActions(Compilat

[PATCH] D52193: RFC: [clang] Multithreaded compilation support -- NOT FOR SUBMIT

tycho added a comment. I rebased this myself on the release_90 branch and I was pleasantly surprised that I got the merge right on the first try (?!), and it actually works well without any significant changes (other than merge conflict resolutions). I've run into two problems with it though:

[PATCH] D52193: RFC: [clang] Multithreaded compilation support -- NOT FOR SUBMIT

angushewlett added a comment. In D52193#1589657 , @aganea wrote: > > In D52193#1589150 , @angushewlett > wrote: > >> They're issued in the right order, but the second doesn't wait for the first >> to complete

[PATCH] D52193: RFC: [clang] Multithreaded compilation support -- NOT FOR SUBMIT

aganea added a comment. In D52193#1589096 , @yurybura wrote: > Do you have any plans to make this PR compatible with trunk? Now MSVC with > /MP builds much faster than clang-cl (at least 2x faster for our project)... I'll get back to this after the vaca

[PATCH] D52193: RFC: [clang] Multithreaded compilation support -- NOT FOR SUBMIT

angushewlett added a comment. In D52193#1457612 , @aganea wrote: > That is strange. As you can’t mix /Yc and /Yu on the command line, MSBuild > should issue two different calls to clang-cl, one with /Yc and one /Yu /MP. > Can you check with ProcMon that

[PATCH] D52193: RFC: [clang] Multithreaded compilation support -- NOT FOR SUBMIT

yurybura added a comment. Dear @aganea, Do you have any plans to make this PR compatible with trunk? Now MSVC with /MP builds much faster than clang-cl (at least 2x faster for our project)... Thanks! Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D52193/new/ http

Re: [PATCH] D52193: RFC: [clang] Multithreaded compilation support -- NOT FOR SUBMIT

Even if I just issue one file with /Yc and none with /Yu, it still fails. Looks like it possibly generates two processes, one to generate the pch and the other to compile and link. A temp file is generated but no final pch; an error is emitted "Unable to read pch file foo.pch". On Sun, 7 Apr 2019,

[PATCH] D52193: RFC: [clang] Multithreaded compilation support -- NOT FOR SUBMIT

aganea added a comment. That is strange. As you can’t mix /Yc and /Yu on the command line, MSBuild should issue two different calls to clang-cl, one with /Yc and one /Yu /MP. Can you check with ProcMon that commands are issued in the right order? Repository: rC Clang CHANGES SINCE LAST ACTI

[PATCH] D52193: RFC: [clang] Multithreaded compilation support -- NOT FOR SUBMIT

angushewlett added a comment. Having applied this patch to the clang latest (which took a bit of doing, and it's possible I messed up along the way) - all working in general, and a roughly 6x speed-up on my i7-7820X. However, PCH support does not seem to work correctly. Specifically, it looks