[Driver] [C++20] [Modules] Support -fmodule-output= (2/2)

[ChuanqiXu]

Summary

Successor of D137058. The intention is described as the second step in D137058. This is helpful if the build systems want to generate these output files in other places which is not the same with -o specified or the input file lived.

---

The discourse discussion is at: https://discourse.llvm.org/t/make-command-line-support-for-c-20-module-uniform-with-gcc/59144

[dblaikie]

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)

[ChuanqiXu]

In 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.

[iains]

In D137059#3898239, @ChuanqiXu wrote:

In 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,

[ChuanqiXu]

In D137059#3898463, @iains wrote:

In D137059#3898239, @ChuanqiXu wrote:

In 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.

[iains]

In D137059#3898482, @ChuanqiXu wrote:

In D137059#3898463, @iains wrote:

In D137059#3898239, @ChuanqiXu wrote:

In 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).

[ChuanqiXu]

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).

Yeah, agreed. Let's avoid the repeating ourselves : )

[ben.boeckel]

There is another motivating factor for 1-phase: the build graph is far simpler. With 2-phase, CMake will have to write out rules to perform:

• source -> .bmi
• .bmi -> .withbmi.o
• source -> .o

because we do not know if a BMI is needed or not. If it isn't we use the latter. If it is, we use the former. Note that this also means we need 2 different .o filenames (as neither make nor ninja doesn't support multiple rules making the same output). This also means that the collator needs to generate a response file for the linker to direct which .o file to use for each TU based on the contents.

Also with 2-phase, it is an open question of whether it actually helps with distributed builds (or anywhere process execution and I/O are expensive compared to some minimal work unit such as, say, Windows compiling from a network drive). Since this is not a bright line, giving the option to say "I know that split BMI is better for me in this instance" and "please combine here" would be handy (depending on actual real-world perf results on real-world projects). Yes, this is a chicken-and-egg cycle :) .

[ChuanqiXu]

In D137059#3899339, @ben.boeckel wrote:

There is another motivating factor for 1-phase: the build graph is far simpler. With 2-phase, CMake will have to write out rules to perform:

• source -> .bmi
• .bmi -> .withbmi.o
• source -> .o

because we do not know if a BMI is needed or not. If it isn't we use the latter. If it is, we use the former. Note that this also means we need 2 different .o filenames (as neither make nor ninja doesn't support multiple rules making the same output). This also means that the collator needs to generate a response file for the linker to direct which .o file to use for each TU based on the contents.

Also with 2-phase, it is an open question of whether it actually helps with distributed builds (or anywhere process execution and I/O are expensive compared to some minimal work unit such as, say, Windows compiling from a network drive). Since this is not a bright line, giving the option to say "I know that split BMI is better for me in this instance" and "please combine here" would be handy (depending on actual real-world perf results on real-world projects). Yes, this is a chicken-and-egg cycle :) .

In my mind, it is OK for CMake to support one-phase compilation model in the short term. And the fact that clang also supports the 2-phase compilation wouldn't affect CMake. Do I understand right? I mean, if the 2-phase compilation wouldn't affect CMake, CMake should be able to ignore it. My thought is that there are many more build systems in the world. And I know many of them would handle the dependency them self fully instead of translate the dependency to other build scripts like make and ninja. And I think it should be good for the compiler to remain different possibilities for different build systems (or tools).

[ben.boeckel]

In D137059#3904256, @ChuanqiXu wrote:

In my mind, it is OK for CMake to support one-phase compilation model in the short term. And the fact that clang also supports the 2-phase compilation wouldn't affect CMake. Do I understand right? I mean, if the 2-phase compilation wouldn't affect CMake, CMake should be able to ignore it. My thought is that there are many more build systems in the world. And I know many of them would handle the dependency them self fully instead of translate the dependency to other build scripts like make and ninja. And I think it should be good for the compiler to remain different possibilities for different build systems (or tools).

Indeed. Even if everything supports 2-phase, I suspect there are cases where 1-phase might still be better. But again, this needs real world numbers and testing to actually perform (more because of build graph shapes than individual TU timings).

[dblaikie]

In D137059#3899339, @ben.boeckel wrote:

There is another motivating factor for 1-phase: the build graph is far simpler. With 2-phase, CMake will have to write out rules to perform:

• source -> .bmi
• .bmi -> .withbmi.o
• source -> .o

because we do not know if a BMI is needed or not. If it isn't we use the latter. If it is, we use the former. Note that this also means we need 2 different .o filenames (as neither make nor ninja doesn't support multiple rules making the same output). This also means that the collator needs to generate a response file for the linker to direct which .o file to use for each TU based on the contents.

I /think/ from @rsmith's comments in the discourse thread, we're more likely to skip/remove the ability to go from ".bmi" -> ".o" and possibly have 2 path options (this is all from @rsmith's comments on discourse) either ".cppm -> {.pcm, .o}" or ".cppm -> .o" + ".cppm -> .pcm" - this'd avoid the need to maintain full V slim pcm, there would never be a pcm that could produce a .o, .pcm would only be sufficient for users, not implementation.

But yeah, maybe we end up with all 3 options in the interim. Though I'd really like to keep the surface area as small as possible, while still allowing room for experimentation. Perhaps experimentation via -Xclang flags until data shows the options are worthwhile beyond those experiments.

Pulling in your (Ben) comment from D137058:

Plus the other compilers offer controls over it; why does Clang have to be different?

Which compilers/flags are you referring to? Arguments from compatibility with GCC are relatively easy to make (though I still have more hesitance for these flags since there's not wide-scale adoption, and I think there's still room to shape the world we want to see and limit the width of the interface/variations we end up having to support long term) & might side-step some of the discussions here.

[ChuanqiXu]

@ben.boeckel gentle ping~

[ChuanqiXu]

Use tests with -###

[ChuanqiXu]

@dblaikie gentle ping~

[dblaikie]

@ben.boeckel

Plus the other compilers offer controls over it; why does Clang have to be different?

Which compilers/flags are you referring to? Arguments from compatibility with GCC are relatively easy to make (though I still have more hesitance for these flags since there's not wide-scale adoption, and I think there's still room to shape the world we want to see and limit the width of the interface/variations we end up having to support long term) & might side-step some of the discussions here.

I'm still curious what about the details of other compilers - I think from the sounds of it, @iains suggested GCC doesn't support this yet so we'll need to pick/name the flag ourselves & he's happy to implement whatever we pick? I guess Microsoft's flag naming is sufficiently differently styled as to offer no useful inspiration? Though wouldn't hurt to know what they name it.

Any other examples you had in mind, Ben?

[ben.boeckel]

In D137059#3934448, @dblaikie wrote:

I'm still curious what about the details of other compilers - I think from the sounds of it, @iains suggested GCC doesn't support this yet so we'll need to pick/name the flag ourselves & he's happy to implement whatever we pick? I guess Microsoft's flag naming is sufficiently differently styled as to offer no useful inspiration? Though wouldn't hurt to know what they name it.

Any other examples you had in mind, Ben?

GCC supports naming the output file by asking the "module mapper" where a module with a given name lives (also used for finding imported modules). MSVC uses the -ifcOutput flag to specify where to write any exported module data to. See this CMake code which handles the "module mapping" for the various compilers: https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmCxxModuleMapper.cxx

[iains]

In D137059#3973016, @ben.boeckel wrote:

In D137059#3934448, @dblaikie wrote:

I'm still curious what about the details of other compilers - I think from the sounds of it, @iains suggested GCC doesn't support this yet so we'll need to pick/name the flag ourselves & he's happy to implement whatever we pick? I guess Microsoft's flag naming is sufficiently differently styled as to offer no useful inspiration? Though wouldn't hurt to know what they name it.

Any other examples you had in mind, Ben?

GCC supports naming the output file by asking the "module mapper" where a module with a given name lives (also used for finding imported modules).

This is using the 'P1184' interface for both tasks - which I think we should keep as a separate mechanism (at least mentally) since we can also use that with clang when we implement it. What the interface returns for the name (via 'P1184') is decoupled from how the name is determined (potentially by a command line argument or from some other build system component).

Currently, GCC does not have a command line spelling for specifying the output module name, which is why I say it's still "up for grabs" (actually it would be polite to ask on [e-mail] for opinions on the spelling, since it would be crazy to have different on at least these two platforms). The spelling of command line options is not IMO bike shedding, it affects day-to-day use of the tools.

[dblaikie]

In D137059#3973096, @iains wrote:

In D137059#3973016, @ben.boeckel wrote:

In D137059#3934448, @dblaikie wrote:

I'm still curious what about the details of other compilers - I think from the sounds of it, @iains suggested GCC doesn't support this yet so we'll need to pick/name the flag ourselves & he's happy to implement whatever we pick? I guess Microsoft's flag naming is sufficiently differently styled as to offer no useful inspiration? Though wouldn't hurt to know what they name it.

Any other examples you had in mind, Ben?

GCC supports naming the output file by asking the "module mapper" where a module with a given name lives (also used for finding imported modules).

This is using the 'P1184' interface for both tasks - which I think we should keep as a separate mechanism (at least mentally) since we can also use that with clang when we implement it. What the interface returns for the name (via 'P1184') is decoupled from how the name is determined (potentially by a command line argument or from some other build system component).

Currently, GCC does not have a command line spelling for specifying the output module name, which is why I say it's still "up for grabs" (actually it would be polite to ask on [e-mail] for opinions on the spelling, since it would be crazy to have different on at least these two platforms). The spelling of command line options is not IMO bike shedding, it affects day-to-day use of the tools.

Alrighty - started a thread here: https://gcc.gnu.org/pipermail/gcc/2022-December/240239.html

[ChuanqiXu]

Rename the option to -fmodule-output according to the discussion from https://gcc.gnu.org/pipermail/gcc/2022-December/240239.html

[iains]

this LGTM ( but please wait for an ack from @dblaikie ) and again thanks for patience in seeing this through.

[ChuanqiXu]

Update after D137058 updated.

[dblaikie]

Nathan had a few questions in the cross-project flag naming thread - could you check/reply to those? I think the right answer is probably "do whatever -o does" but would be good to verify that behavior makes sense, maybe explicitly test it in some way if it's significant enough/requires any work to support getting that behavior? (if it falls out naturally from some existing file IO handling we have, I'm less worried about testing it separately)

[dblaikie]

In D137059#3989856, @dblaikie wrote:

Nathan had a few questions in the cross-project flag naming thread - could you check/reply to those? I think the right answer is probably "do whatever -o does" but would be good to verify that behavior makes sense, maybe explicitly test it in some way if it's significant enough/requires any work to support getting that behavior? (if it falls out naturally from some existing file IO handling we have, I'm less worried about testing it separately)

Oh, I guess those questions ^ are really more applicable to the previous patch in the series, that introduces writing the file out anyway - the ability to specify the name of the file probably has no impact/shouldn't have any impact on the answers to the questions, so this patch looks good - please consider those issues in the other patch.

[ChuanqiXu]

Update as the dependent one changes.

[ChuanqiXu]

Update since the dependent one changed.

[ChuanqiXu]

Update since the dependent one changes.

[ChuanqiXu]

Update since the dependent one changed.

[ChuanqiXu]

Update since the dependent one changes.

clang/include/clang/Driver/Options.td

 def fprebuilt_module_path : Joined<["-"], "fprebuilt-module-path=">, Group<i_Group>,
   Flags<[NoXarchOption, CC1Option]>, MetaVarName<"<directory>">,
   HelpText<"Specify the prebuilt module path">;
 defm prebuilt_implicit_modules : BoolFOption<"prebuilt-implicit-modules",
   HeaderSearchOpts<"EnablePrebuiltImplicitModules">, DefaultFalse,
   PosFlag<SetTrue, [], "Look up implicit modules in the prebuilt module path">,
   NegFlag<SetFalse>, BothFlags<[NoXarchOption, CC1Option]>>;
 
+def fmodule_output_EQ : Joined<["-"], "fmodule-output=">, Flags<[NoXarchOption, CC1Option]>,
+  HelpText<"Save intermediate module file results when compiling a standard C++ module unit.">;
 def fmodule_output : Flag<["-"], "fmodule-output">, Flags<[NoXarchOption, CC1Option]>,
   HelpText<"Save intermediate module file results when compiling a standard C++ module unit.">;
 
 def fmodules_prune_interval : Joined<["-"], "fmodules-prune-interval=">, Group<i_Group>,
   Flags<[CC1Option]>, MetaVarName<"<seconds>">,
   HelpText<"Specify the interval (in seconds) between attempts to prune the module cache">,
   MarshallingInfoInt<HeaderSearchOpts<"ModuleCachePruneInterval">, "7 * 24 * 60 * 60">;
 def fmodules_prune_after : Joined<["-"], "fmodules-prune-after=">, Group<i_Group>,

clang/lib/Driver/Driver.cpp

if (CrashDirectory) {
     } else {
       TmpName = GetTemporaryPath(Prefix, Suffix);
     }
   }
   return C.addTempFile(C.getArgs().MakeArgString(TmpName));
 }
 
 // Calculate the output path of the module file when compiling a module unit
-// with the `-fmodule-output` option specified. The behavior is:
-// - If the output object file of the module unit is specified, the output path
+// with the `-fmodule-output` option or `-fmodule-output=` option specified.
+// The behavior is:
+// - If `-fmodule-output=` is specfied, then the module file is
+//   writing to the value.
+// - Otherwise if the output object file of the module unit is specified, the
+// output path
 //   of the module file should be the same with the output object file except
 //   the corresponding suffix. This requires both `-o` and `-c` are specified.
 // - Otherwise, the output path of the module file will be the same with the
 //   input with the corresponding suffix.
 static const char *GetModuleOutputPath(Compilation &C, const JobAction &JA,
                                        const char *BaseInput) {
   assert(isa<PrecompileJobAction>(JA) && JA.getType() == types::TY_ModuleFile &&
-         C.getArgs().hasArg(options::OPT_fmodule_output));
+         (C.getArgs().hasArg(options::OPT_fmodule_output) ||
+          C.getArgs().hasArg(options::OPT_fmodule_output_EQ)));
+
+  if (Arg *ModuleOutputEQ =
+          C.getArgs().getLastArg(options::OPT_fmodule_output_EQ))
+    return C.addResultFile(ModuleOutputEQ->getValue(), &JA);
 
   SmallString<64> OutputPath;
   Arg *FinalOutput = C.getArgs().getLastArg(options::OPT_o);
   if (FinalOutput && C.getArgs().hasArg(options::OPT_c))
     OutputPath = FinalOutput->getValue();
   else
     OutputPath = BaseInput;
 
if (JA.getType() == types::TY_PP_Asm &&
     // Use /Fa and the input filename to determine the asm file name.
     StringRef BaseName = llvm::sys::path::filename(BaseInput);
     StringRef FaValue = C.getArgs().getLastArgValue(options::OPT__SLASH_Fa);
     return C.addResultFile(
         MakeCLOutputFilename(C.getArgs(), FaValue, BaseName, JA.getType()),
         &JA);
   }
 
-  if (MultipleArchs && C.getArgs().hasArg(options::OPT_fmodule_output))
+  bool SpecifiedModuleOutput =
+      C.getArgs().hasArg(options::OPT_fmodule_output) ||
+      C.getArgs().hasArg(options::OPT_fmodule_output_EQ);
+  if (MultipleArchs && SpecifiedModuleOutput)
     Diag(clang::diag::err_drv_module_output_with_multiple_arch);
 
   // If we're emitting a module output with the specified option
   // `-fmodule-output`.
   if (!AtTopLevel && isa<PrecompileJobAction>(JA) &&
-      JA.getType() == types::TY_ModuleFile &&
-      C.getArgs().hasArg(options::OPT_fmodule_output))
+      JA.getType() == types::TY_ModuleFile && SpecifiedModuleOutput)
     return GetModuleOutputPath(C, JA, BaseInput);
 
   // Output to a temporary file?
   if ((!AtTopLevel && !isSaveTempsEnabled() &&
        !C.getArgs().hasArg(options::OPT__SLASH_Fo)) ||
       CCGenDiagnostics) {
     StringRef Name = llvm::sys::path::filename(BaseInput);
     std::pair<StringRef, StringRef> Split = Name.split('.');

clang/test/Driver/module-output.cppm

 // RUN: %clang -std=c++20 %t/Hello.cppm %t/AnotherModule.cppm -fmodule-output -o \
 // RUN:   %t/output/a.out -### 2>&1 | FileCheck  %t/AnotherModule.cppm
 //
 // Tests that clang will reject the command line if it specifies -fmodule-output with
 // multiple archs.
 // RUN: %clang %t/Hello.cppm -fmodule-output -arch i386 -arch x86_64 -### -target \
 // RUN:   x86_64-apple-darwin 2>&1 | FileCheck %t/Hello.cppm -check-prefix=MULTIPLE-ARCH
 
+// Tests that the .pcm file will be generated in the same path with the specified one
+// in the comamnd line.
+// RUN: %clang -std=c++20 %t/Hello.cppm -fmodule-output=%t/pcm/Hello.pcm -o %t/Hello.o \
+// RUN:   -c -### 2>&1 | FileCheck %t/Hello.cppm --check-prefix=CHECK-SPECIFIED
+
 //--- Hello.cppm
 export module Hello;
 
 // CHECK: "-emit-module-interface" {{.*}}"-main-file-name" "Hello.cppm" {{.*}}"-o" "{{.*}}/output/Hello.pcm" "-x" "c++" "{{.*}}/Hello.cppm"
 // CHECK: "-emit-obj" {{.*}}"-main-file-name" "Hello.cppm" {{.*}}"-o" "{{.*}}/output/Hello.o" "-x" "pcm" "{{.*}}/output/Hello.pcm"
 
 // MULTIPLE-ARCH: option '-fmodule-output' can't be used with multiple arch options
 
+// CHECK-SPECIFIED: "-emit-module-interface" {{.*}}"-main-file-name" "Hello.cppm" {{.*}}"-o" "{{.*}}/pcm/Hello.pcm" "-x" "c++" "{{.*}}/Hello.cppm"
+// CHECK-SPECIFIED: "-emit-obj" {{.*}}"-main-file-name" "Hello.cppm" {{.*}}"-o" "{{.*}}/Hello.o" "-x" "pcm" "{{.*}}/pcm/Hello.pcm"
+
 //--- AnotherModule.cppm
 export module AnotherModule;
 // CHECK: "-emit-module-interface" {{.*}}"-main-file-name" "Hello.cppm" {{.*}}"-o" "{{.*}}/Hello.pcm" "-x" "c++" "{{.*}}/Hello.cppm"
 // CHECK: "-emit-obj" {{.*}}"-main-file-name" "Hello.cppm" {{.*}}"-o" "{{.*}}/Hello-{{.*}}.o" "-x" "pcm" "{{.*}}/Hello.pcm"
 // CHECK: "-emit-module-interface" {{.*}}"-main-file-name" "AnotherModule.cppm" {{.*}}"-o" "{{.*}}/AnotherModule.pcm" "-x" "c++" "{{.*}}/AnotherModule.cppm"
 // CHECK: "-emit-obj" {{.*}}"-main-file-name" "AnotherModule.cppm" {{.*}}"-o" "{{.*}}/AnotherModule-{{.*}}.o" "-x" "pcm" "{{.*}}/AnotherModule.pcm"