[PATCH] D134267: [C++] [Modules] Support one phase compilation model for named modules

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added subscribers: ruoso, ben.boeckel.
ChuanqiXu added a comment.

>> Although modular code is user-facing - BMIs are an implementational detail, right?
>
> but I don't think BMIs are an implementation detail, anymore than object files are - users should/will be as aware of BMIs as they are of .o files - there build artifacts that need to be cached, can be out of date, can be deleted/maybe copied/moved around in limited ways, have to be passed to other tools in the build pipeline. Not sure what term to use, I guess compilers don't often have warnings/errors/diagnostics that explicitly talk about "object files" - so maybe in a similar sense they won't explicitly talk about "binary module artifact files" but maybe?

Yeah, agreed. I guess @iains 's meaning may be "if the tool chains are ready enough one day, then the end user won't need to touch BMIs directly". Yeah, it looks true. Nowadays, many c++ programmers don't need to touch the `.o` files since the build systems have taken care for it (from my personal experience). But from the perspective of a compiler, the concept of `BMI` may be necessary. I remember when I wrote the documents for modules, I used the term "module file" at first. Then @ruoso corrected me that we should use `BMI` here. So I think the use of the term `BMI` may be correct here.

> The build system still needs to know that B.cppm depends on A.cppm - and once it knows that, it's not a huge cost for it to know the name of the file that represents that dependency and is produced by A.cppm and passed to B.cppm, I think?

In a private chat with Kitware guys, they told me if the one phase compilation wasn't supported, they can mock it by replacing the original command by the combination of:

  clang++ -std=c++20 --precompile src.cppm -o src.pcm
  clang++ -std=c++20 src.pcm --precompile src.o

but the `pcm` files won't be depended directly. So it may be harder, I am not sure. @ben.boeckel any update?

> In short - seems like we should separate out the cache discussion from the "one phase" compilation in the sense of a single build action that takes a .cppm and generates both a .o and a .pcm in one compiler/driver invocation. (maybe something like this is what @iains has already sent out in another review?)

Agreed.

> to @iains point about "it'd be good if we didn't have to invoke two underlying commands from the one drivter invocation" - yeah, agreed. Though I wouldn't mind one step being "add the driver interface" and another being "fix whatever serialization isuse/etc/ might stand in the way of doing .cppm->{.o,.pcm} in a single action without serialization, so we can then start stripping stuff out of the .pcm since it'll only need to contain the interface, and not have to worry about having enough info for .o generation anymore"

(I guess you're saying `without deserialization`)

Agreed in the higher level.

But what do you mean about `stripping stuff out of the .pcm`? Do you mean to remove some function bodies when writing the BMI? If yes, it'll be problematic.  When we did so, when other TU imports the BMI, it won't see the function bodies it could see before. This will prevent optimization. It'll be good as an optional flag so that the user know what the effect is. But it might not be good to  do so by default. (Although this paragraph starts to talk about other topics)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134267/new/

https://reviews.llvm.org/D134267