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

Iain Sandoe via cfe-commits cfe-commits at lists.llvm.org
Thu Nov 9 21:31:53 PST 2023


iains wrote:


> > Whether we re-use wrapper code or make some new code is an implementation detail.
> > It does not actually prevent you from taking the two-phase approach ( currently , --precompile will be unchanged in action).
> 
> It doesn't prevent the two-phase compilation model indeed. But it introduces a new way about how we produce BMIs.

It allows us to produce a new kind of BMI - that carries a minimised content, applicable to the interface, otherwise it is no different to the case where two command lines are needed to produce an object and BMI..

We can also produce the old "full implementation content" BMI if there is some reason to do so.

> The new way skipped the part of jobs we did in drivers for `.cppm`. Then this is the divergence that I am concerning too.

I'm a bit confused by what you are saying here; the driver does not do any of the work, it simply prepares cc1 commands that are then executed by the compiler.  In the current case, we prepare two command lines one that builds an Implementation BMI and one that consumes that to produce an object.

We can simplify the driver because now it only needs to prepare one command line (even in the case that we decide to emulate the existing scheme by executing a `--precompile` followed by a `-c`.)

The difficulty that I have pointed out is that if we preserve the existing scheme but want an Interface BMI - we then have to produce a third compile line in the driver that takes the Implementation BMI and produces the Interface BMI from it.  We cannot avoid producing the intermediate BMI here because the jobs are created by the driver and executed by the compiler and we need to Implementation BMI to produce the object.

> In my mind, the proper solution is to introduce a new frontend action that combines GenerateModuleInterfaceAction and CodeGenAction.

Initially, that seems like a great idea - until you look at how many possible compile jobs can combine with production of a BMI - for example, `-save-temps`, `-S`, `-emit-llvm` .. it would be a bad user experience if the only one that works was `-c`, right?

> Then in the driver part, we generate the new action in the precompile phase for some combination of the input then we can skip the `Compile` phase.

We no longer need the driver to try to generate multiple steps, so it does not need to skip anything.
```
                                                    -- optimiize - codegen [obj]
                                                  /
 [src] => preprocess = > parse => sema [full BMI]
                                                  \
                                                    -- filter [Interface BMI]
                            --precompile     ^ 
```
                            


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


More information about the cfe-commits mailing list