Skip to content

[6.2][Caching] Swift Caching Dependency Scanning Improvements #81720

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: release/6.2
Choose a base branch
from

Conversation

cachemeifyoucan
Copy link
Contributor

This is a combined nomination for 4 different changes but they are highly dependent on each other and have merge conflicts that can be hard to resolve if picking up individually. They combined together should give about 4% overall speed up for swift caching build for both cold/hot cache for a single target swift projects. They also combined to fix module sharing problems that can have significant overhead for multi-target workspaces, and also fixes a corder case that can trigger dependency tracking issue in build system for incremental build. The changes have gone through a full qualification without finding regressions.

Individual changes:

1

  • Explanation: Using IncludeTree::FileList to concat the include tree file systems that are passed on the command-line. This significantly reduce the command-line size, and also makes the cache key computation a lot faster.
  • Scope: Make build log easier to read and also has performance benefits especially for batched builds.
  • Issues: rdar://148752988
  • Original PRs: [Caching] Reduce the number of cas ID passed on frontend commandline #81264
  • Risk: Low. Swift caching only and no functional change intended.
  • Testing: Unit Tests.
  • Reviewers: @benlangmuir

2

  • Explanation: Removing out of dated CASFS based clang module implementation in order to remove one of the ClangImporter construction that pulls in the vfs overlay file that is no longer needed. Those extra VFS overlays also causes significant overhead for building multiple targets when some of the module can be shared when those vfs overlays are not used for module building.
  • Scope: Minor perf improvements for dependency scanning and potentially big perf gain from module sharing.
  • Issues: rdar://151339073
  • Original PRs: [Caching] Remove CASFS based clang module implementation #81494
  • Risk: Low. Swift caching only.
  • Testing: Existing unit tests.
  • Reviewers: @artemcm

3

4

  • Explanation: Improve swift dependency scanning time by significantly improve the time to bridge clang scanning results to swift compiler invocation.
  • Scope: Removes the overhead of round tripping clang cc1 arguments which is a big chunk of time in dependency scanning.
  • Issues: rdar://151705822
  • Original PRs: [DependencyScanning] Avoid extra cc1 arg round-trip to speed up bridging #81454
  • Risk: Low
  • Testing: Unit Test
  • Reviewers:

Using IncludeTree::FileList to concat the include tree file systems that
are passed on the command-line. This significantly reduce the
command-line size, and also makes the cache key computation a lot
faster.

rdar://148752988
(cherry picked from commit 201e4fa)
Remove the CASFS based clang module implemenation as it is not longer
used.

(cherry picked from commit 3c81c1c)
After removing the CASFS implementation for clang modules, there is no
need to capture clang extra file that sets up the VFS for the clang
modules since all content imported by ClangImporter is dependency
scanned and available via include-tree. This saves more ClangImporter
instance when caching is enabled.

Update the test to check that clang content found via `-Xcc` VFS options
can currently work without capture the headermaps and vfs overlays.

(cherry picked from commit 1506a0d)
Use `resetBenignCodeGenOptions()` from clang dependency scanner to clear
the swift explicit module build cc1 arguments. This fixes the problem
that CurrentWorkingDirectory is leaking through
`-fcoverage-compilation-dir` that can cause extra module variants when
caching is enabled. This also avoid the duplicating the logics for
clearing CodeGen options inside Swift.

rdar://151395300
(cherry picked from commit 531227d)
Use the underlying compiler invocation inside module scanning result to
speed up the clang module dependency bridging. This avoids converting
cc1 arguments to compiler invocation and back, just to modify the cc1
arguments needed for building PCM using swift-frontend.

rdar://151705822
(cherry picked from commit 391446d)
@cachemeifyoucan cachemeifyoucan requested a review from a team as a code owner May 22, 2025 18:34
@cachemeifyoucan
Copy link
Contributor Author

@swift-ci please test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants