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