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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
