[all-commits] [llvm/llvm-project] 827b5d: [clang][deps] Parallelize module compilations (#18...

[Jan Svoboda via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 827b5d9423083da6111ddc382c9d4449ff853949
      https://github.com/llvm/llvm-project/commit/827b5d9423083da6111ddc382c9d4449ff853949
  Author: Jan Svoboda <jan_svoboda at apple.com>
  Date:   2026-02-12 (Thu, 12 Feb 2026)

  Changed paths:
    M clang/include/clang/DependencyScanning/DependencyScanningService.h
    M clang/include/clang/Serialization/ASTReader.h
    M clang/lib/DependencyScanning/DependencyScannerImpl.cpp
    M clang/lib/DependencyScanning/DependencyScanningService.cpp
    M clang/tools/clang-scan-deps/ClangScanDeps.cpp
    M clang/tools/clang-scan-deps/Opts.td

  Log Message:
  -----------
  [clang][deps] Parallelize module compilations (#180047)

In a typical build, the build system schedules many TUs from the same
target to be scanned/compiled at the same time. These TUs tend to depend
on a similar set of modules, and they usually keep their imports
alphabetically sorted. The nature of implicit modules then means that
scanning these TUs reduces into a single-threaded computation, since
only one TU wins the race to compile the common dependency module, and
the same thread/process keeps being responsible for compiling all
transitive dependencies of such module.

This PR makes use of the single-module-parse-mode in a new scanning step
that runs at the start of each TU scan. In this step, the scanner
quickly discovers unconditional module dependencies of the TU without
blocking on its compile. This typically discovers plenty of work to keep
the available threads busy and compile modules in more parallel fashion.
Modules discovered here are compiled on separate threads right away in
the same two-step fashion.

The second step then performs the regular dependency scan of the TU
where each module import is a blocking operation. However, by this time,
the first scanning step most likely already compiled the majority of
modules, so there's actually little to no waiting happening here. The
compiler only deserializes previously-built modules.

This is a barebones implementation with some known quirks marked in
FIXME comments. I will continue working on performance and polish once
this lands.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications