@@ -377,15 +377,14 @@ the result cache doesn't unnecessarily shrink again.
377377# Incremental Compilation and the Compiler Backend
378378
379379The compiler backend, the part involving LLVM, is using the query system but
380- it is not implemented in terms of queries itself. As a consequence
381- it does not automatically partake in dependency tracking. However, the manual
382- integration with the tracking system is pretty straight-forward. The compiler
383- simply tracks what queries get invoked when generating the initial LLVM version
384- of each codegen unit, which results in a dep-node for each of them. In
385- subsequent compilation sessions it then tries to mark the dep-node for a CGU as
386- green. If it succeeds it knows that the corresponding object and bitcode files
387- on disk are still valid. If it doesn't succeed, the entire codegen unit has to
388- be recompiled.
380+ it is not implemented in terms of queries itself. As a consequence it does not
381+ automatically partake in dependency tracking. However, the manual integration
382+ with the tracking system is pretty straight-forward. The compiler simply tracks
383+ what queries get invoked when generating the initial LLVM version of each
384+ codegen unit (CGU), which results in a dep-node for each CGU. In subsequent
385+ compilation sessions it then tries to mark the dep-node for a CGU as green. If
386+ it succeeds, it knows that the corresponding object and bitcode files on disk
387+ are still valid. If it doesn't succeed, the entire CGU has to be recompiled.
389388
390389This is the same approach that is used for regular queries. The main differences
391390are:
0 commit comments