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

[Iain Sandoe via Phabricator via cfe-commits]

iains added a comment.

In D134267#3863938 <https://reviews.llvm.org/D134267#3863938>, @ChuanqiXu wrote:

>>> 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)



- Yes, all of this stuff is important (and, yes, we are drifting into other [related] topics) - we already have a mechanism for providing function bodies to optimisation [LTO] - I do not think we should want to make module interfaces larger than necessary to duplicate that functionality  (the reason we do now is because all the information needs to be present to feed into codegen) - it has been a long-term objective (I think listed even in @rsmith 's modules TODO list) to remove the unneeded BMI content.

- Actually, my point was meant to be quite simple and directly related to this patch that the choice of options name should be something that would be obvious to the end-user, ideally we should have related options named similarly and we should avoid using terms that are familiar to compiler engineers but not necessarily to the end user.


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

https://reviews.llvm.org/D134267