================
@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+---------------------------------
+
+This section is primarily for build system vendors. For end compiler users,
----------------
ChuanqiXu9 wrote:
> This may have been discussed somewhere that I missed, please point me to that
> if that's the case.
>
> I was putting a little more thought into it and am wondering what would be a
> way for the build systems to take advantage of that?
>
> When compiling something that dependends on modules, the build system will
> need to check if any of the (transitive) dependencies of the modules changes,
> right? Because any BMI that was changed in the transitive set can potentially
> affect the result of the current compilations.
>
> So even if direct dependencies did not change (because of this optimization),
> despite a change in the deeper transitive dependency, the build system still
> can't reuse the result and has to rerun the compile.
Yes, and this is the reason why it is experimental.
>
> We only know that the output BMI wasn't affected by any of the transitive
> changes **after** we finish compiling it and can compare the outputs, right?
> But the build system needs to know about it **before** the compilation
> happens to avoid recompilations.
>
> I suspect I'm missing something, but don't know what...
It is not about to avoid the re-compilation for that unchanged BMI, but for
other TUs that only dependent on the unchanged BMI. For example,
```
// a.cppm
export module a;
// intentional empty
```
```
// b.cppm
export module b;
import a;
// intentional empty
```
```
// c.cpp
import b;
...
```
For this example, every time `a.cppm` changes, we need to recompile `b.cppm`.
But if the BMI of module `B` doesn't change at all, it should be good to not
recompile `c.cpp`. Do this make sense?
https://github.com/llvm/llvm-project/pull/96453
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
