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