iains added a comment. In D137059#3898482 <https://reviews.llvm.org/D137059#3898482>, @ChuanqiXu wrote:
> 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. Not sure what you mean here; If there is only one user of a PCM then it does not need to be produced (waste of disk space and CPU cycles); If there are many uses of it (as we might expect in a massively parallel distributed build system) then distributing the PCM is important and its availability predicates progress of other builds - from previous discussions in WG21 there are users that care very much about the size of distributed artefacts. > --- > >> 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. Having a mechanism to specify the place for the file is fine by me ( I was only commenting on the motivation point for separate pcm and object phases ). (I think we should move this discussion somewhere else, again - unless it is considered a key factor in deciding on this patch, I have no further comments). 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
