[PATCH] D144844: [C++20] [Modules] Offer -fno-import-inter-module-function-defs to avoid duplicated compilation in modules

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

In D144844#4197067 <https://reviews.llvm.org/D144844#4197067>, @dblaikie wrote:

> I don't think of this as a performance regression for users though - this functionality's never really "shipped" so we get to choose what the baseline is.
>
> And I think a reasonable baseline to compare to isn't this implementation we don't think is ideal (because of the build invalidation issues, if nothing else, caused by having thick PCMs) - I think the baseline is what a users non-modular code is. And in non-modular code these non-inline functions would be in the implementation files, not able to cross-TU inline without LTO.
>
> I think not providing definitions of non-inline functions for cross-TU optimizations is not a regression, but exactly in-line with existing non-modular behavior, which is totally fine.

Yeah, I refer "regression"  to compare the performance of modular codes with the non modular codes. Since no users will be happy if they found the performance goes down after they convert their existing library to modules.

Then the problem is that the implicitly inline functions in headers may be non-inline functions in modules.   And we made some simple experiments for the patch, we observed performance regression indeed.

In D144844#4197646 <https://reviews.llvm.org/D144844#4197646>, @iains wrote:

> In D144844#4195633 <https://reviews.llvm.org/D144844#4195633>, @ChuanqiXu wrote:
>
>>> However, "performance" also includes compilation speed in the 'no optimisation, debug' case - that is also considered very important. So, perhaps, the short-term approach should be (as @dblaikie suggested) to include the bodies for -O >= 3?
>>
>> I don't think so. I think "performance" refers to the runtime performance generally. I don't believe the normal users will be happy if modules will decrease the performance of their program in any means. So I think we should include the bodies by default.
>
> I think I must be misunderstanding something here.
>
> The default for clang is to compile without optimisation - this benefits the compile-edit-debug cycle, by providing output that is closest to the original source, and quickest to compile.
>
> The user should not be expecting any optimisations to be applied unless they supply `-ON` (n fact, they might well complain if we optimise something that makes debugging harder).
>
> So, we should try to ensure that adding modules supports that model - and provides the quickest and closest to the original sources for the default options.  If the user wants better optimisation (at the expense of longer compile times), then they provide `-ON`, right?

Oh, we are talking the case that the users will use `-ON` as default. Since every C++ programs will use `-ON` in practice.




And I am still wondering how thin the thin BMI will be by removing the non-inline function bodies. For example, we'll still need to contain the function bodies for templates, right? So I guess if we want a thin BMI, we need more refactoring to the current pcm format, which requires more working.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144844