ChuanqiXu added a comment. In D137059#3898463 <https://reviews.llvm.org/D137059#3898463>, @iains wrote:
> In D137059#3898239 <https://reviews.llvm.org/D137059#3898239>, @ChuanqiXu > wrote: > >> In D137059#3896661 <https://reviews.llvm.org/D137059#3896661>, @dblaikie >> wrote: >> >>> Could you link to the email/discourse discussion about supporting this mode >>> (I think you've linked it in other discussions, be good to have it for >>> reference here & Probably in the other review)? (I'm wondering if we need a >>> new flag for this, or if it'll be OK to change the driver behavior to >>> always coalesce the .cppm->.pcm->.o path into a single step, for instance - >>> I realize this is a somewhat breaking change but may be acceptable given >>> that modules aren't widely deployed yet) >> >> Done. From my reading, in that discourse discussing, we're not talking about >> to add the new flags. I add the flag since I don't want the `.pcm` file >> pollutes the user space accidentally. >> >>> if it'll be OK to change the driver behavior to always coalesce the >>> .cppm->.pcm->.o path into a single step >> >> I am not sure what you mean. Do you talk about to forbidden the original >> 2-phase compilation model? If so, I think it is definitely the wrong >> direction. The 2-phase compilation model should be the correct direction in >> the long term since it has higher parallelism. > > I am not convinced about this second point as motivation for this direction; > it comes with some significant resource tradeoffs (compared with the proposed > [near] future version of producing the PCM and the object from one invocation > of the FE): > > - it requires multiple instantiations of the FE > - it blocks the objective of reducing the content of module interfaces (so > that they only contain the information that pertains to the interface) - > since requiring source -> pcm, pcm -> object means that the PCM has to > contain all the information necessary to generate the object. > - in terms of parallelism, the interface PCM has to be generated and > distributed - the parsing and serialisation has to be complete before the PCM > can be distributed; that process is the same regardless of whether the FE > invocation also produces an object. > > So, I would suggest that we would move to a single invocation of the compiler > to produce the PCM and object as the default; if the user has a specific > reason to want to do the two jobs separately then thay could still do so ( > -fmodule-only / --precompile ) at the expense of two invocations as now, > (so that they only contain the information that pertains to the interface) No, we can't do this. It hurts the performance. > it requires multiple instantiations of the FE Agreed. But if we care about this, I think it may be best to allow the current 2 phase compilation model only. And we forbid the compilation from module unit to object files directly. This is cleanest approach. > in terms of parallelism, the interface PCM has to be generated and > distributed - the parsing and serialisation has to be complete before the PCM > can be distributed; that process is the same regardless of whether the FE > invocation also produces an object. I think the distribution doesn't matter with parallelism. For parallelism, I mean, for the scan-based build systems, the compilation of A must wait until the dependent module B compiles to object files, which is significantly worse than the 2 phase compilation. --- > So, I would suggest that we would move to a single invocation of the compiler > to produce the PCM and object as the default; So the question would be where is the destination place? And if we would offer an option to allow the user to specify the place? This question is discussed in https://reviews.llvm.org/D137058. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D137059/new/ https://reviews.llvm.org/D137059 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
