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

Tue Nov 1 01:03:03 PDT 2022

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