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