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

Tue Mar 14 10:29:17 PDT 2023

iains added a comment.

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

> Seem to recall @iains and others were concerned about the number of modules flags - this one I'd be inclined to suggest we shouldn't add if possible. If one way or the other is generally better - we should, at least initially, dictate that behavior entirely until someone can demonstrate divergent use cases that seem reasonable to support but must have different behavior here.

Agreed, [IMO, at least] we have a very large set of modules options, and expanding that should only be done if no sensible alternative can be found (we are already seeing users getting confused about which ones apply in each case).

A second point here - that (once we have the ability to generate object and PCM in the same compilation) that we will move to elide the function bodies for non-inline and non-dependent cases from the PCM, so that this problem will magically "go away" (to restore the current behaviour, we'd then be using some optimisation control to avoid the elision, I suppose).

> The performance of cross-module inlining could be achieved with something like ThinLTO if we were to lean in favor of not allowing cross-module inlining by default, for instance.

+1 this seems exactly what LTO is intended for (also there are folks who seem to have an expectation that the BMI somehow magically contains an optimised representation of the source - which again is the province of LTO).

> But if there are particular idioms where cross-module inlining is disadvantageous, perhaps we can implement better ways for clang to detect them (or if they're undetectable, offer users a way to annotate their code, maybe).

I'd be interested to see an example where cross-module function body imports somehow beats the equivalent LTO.

> Could we key off -Os or -Oz or some other existing optimization/compile time tradeoff flags instead of introducing a new flag?

That's an interesting idea .. I'd suggest we should default the behaviour to "off" (so that compilation speed is prioritised for default options, as usual) and then maybe enable import of function bodie at O3 <https://reviews.llvm.org/owners/package/3/> or so? [maybe even an optimisation representative of LTO .. so that when we slim the BMIs down we do not get complaints about regression in code performance].

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144844