Sources compile one at a time, whatever --jobs #271

Summary

Every compilation of a source holds one global lock, gCompileInvokeMutex, and moves the whole process to its compile command's directory with ScopedCurrentPath (InputPipeline.cpp L43-L51 and L920-L942 at db7fb25). The --jobs threads load modules in parallel, but compile one source at a time: on a C++ project, where compiling takes most of the loading, --jobs barely shortens it.

Its comment gives two reasons. The analyzer moves the whole process to the directory of each compile command, so two compilations must not overlap. And two threads compiling at once hung on the first compilation of a run, on LLVM's global state: coretrace-compiler made the initialization of LLVM's targets thread-safe the day the lock was added (5aa46bc, 2026-09-06, in v0.10.0). CoreTrace/coretrace-compiler#262 now gives each compilation a working directory of its own, without moving the process.

Measured on macOS arm64 (M3, 8 cores) with LLVM 20.1.2, coretrace-compiler built from its main branch, --format=json --timing, no IR cache, medians of 3 to 5 runs: --jobs=2 loads the analyzer's own 53 sources in 42.2 s against 44.1 s with --jobs=1, and 8 C++ files that each include 11 standard headers in 4.03 s against 3.81 s.

Proposal

Pass each compile command's directory to coretrace-compiler as -working-directory, and let compilations share the lock. Some still hold it alone, since coretrace-compiler says they change state that the whole process shares: those that pass -mllvm, -mdebug-pass, -mlimit-float-precision or -ftime-report, and those with -fno-integrated-cc1, whose jobs run as programs.

Related: #199, whose 14-minute loading phase on botan compiled one source at a time.