@@ -377,15 +377,14 @@ the result cache doesn't unnecessarily shrink again.
377
377
# Incremental Compilation and the Compiler Backend
378
378
379
379
The 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.
389
388
390
389
This is the same approach that is used for regular queries. The main differences
391
390
are:
0 commit comments