[clang] Llvm modules on demand bmi (PR #71773)

Chuanqi Xu via cfe-commits cfe-commits at lists.llvm.org
Wed Nov 8 22:33:25 PST 2023


ChuanqiXu9 wrote:

This is a little bit far from what I imaged.

There are 2 things in the patch. One is to generate the BMI and the object file in one phase (phase here means preprocess, precompile, compile, ...). Another is to allow us to generate BMI from a `.cpp` file. (Currently we only do this for `.cppm` file or `-x c++-module` file).

The first thing is in my TODO too. But my consideration is more about efficiency. Currently, the one phase compilation model (I found the term `phase` may be ambiguous in the context) used by cmake is actually compile the module source file to a BMI and compile the BMI to an object file.

```
x.cppm -> x.pcm -> x.o
```

But after we introduced thin BMI, it looks inefficient to write the AST twice. So it is on my TODO list after we land the thin BMI patch. BTW, I think we should do thin in CodeGen action instead of hacking on WrappedASTConsumer.

For the second thing, I am curious that if it is necessary now? Or what will it block? I mean, the build systems or the cmake, require to mark the module unit ahead of time. Then the build systems will pass `-x c++-module` now for module units. Then the suffixes are not a thing for users.

And to me, the current mechanism for `.cppm` (or `-x c++-module`) in the driver side works pretty well.  And if we introduce the mechanism to produce BMI for `.cpp`, it implies that we need to maintain both paths. It is super embracing to me.

> in the AST consumer on the BMI side doing suitable filtering to eliminate the content that is not part of the interface, that is either not needed (or in some cases positively unhelpful to consumers).

I believe we should do this in ASTWriters. Also this should be part of thin BMI.

https://github.com/llvm/llvm-project/pull/71773


More information about the cfe-commits mailing list