[PATCH] D137059: [Driver] [Modules] Introduce -fsave-std-c++-module-file= to specify the path of the module file (2/2)

[Iain Sandoe via Phabricator via cfe-commits]

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